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The  Topographic  Support  System  (TSS)  is  intended  to  supply  all  of 
the  Army's  requirements  for  topographic  and  military  geographic  infor- 
mation during  a short,  high  intensity  combat  situation.  The  purpose  of 
the  System  Analysis,  which  is  described  in  this  report,  was  to  determine: 
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- whether  or  not  the  TSS  had  over  or  under  capacity 
to  locate  '^bottlenecks*1,  (if  any),  in  the  TSS 
which  restrict  production  flow 
to  recommend  solutions  to  problems,  if  any  were 
detected . 

A discrete  events  System  Simulation  Model  was  utilized  as  the 
analysis  tool.  The  language  is  one  that  is  commonly  used  in  the 
analysis  of  large-scale  assembly  and  production  facilities,  ware- 
housing operations,  etc. 

A '^scenario",  consisting  of  39  different  product  requests, 
together  with  their  frequency  of  occurrence,  priority,  number  of 
originals  and  final  copies,  etc.,  was  generated.  These  product 
requests  were  entered  into  the  TSS  at  the  rate  of  three  per  hour 
for  a lAA-hour  period,  both  to  simulate  the  high  intensity  combat 

environment  and  also  to  stress  the  system... 

V\ 

The  TSS  configuration,  as  of  January  1978,  was  simulated 
utilizing  the  CDC  6600  computer.  Under  capacity  was  found  in 
Drafting  and  throughput  problems  were  found  in  the  production 
of  products  which  utilize  aerial  imagery.  Drafting  capacity  was 
then  doubled,  and  the  under  capacity  was  eliminated.  Doubling  of 
two  other  Modules,  containing  photo  processing  type  equipments, 
improved  throughput  considerably,  but  did  not  resuJ t in  achieving 
adequate  production  rates. 

Upon  detailed  examination  of  the  results,  it  became  apparent 
that  the  problem  with  Image  Based  Products  resulted  from  inter- 
mediate products  recycling  through  the  same  equipments.  Often 
these  equipments  were  located  in  different  Modules,  further  in- 
creasing delays. 

Minor  modifications  were  made  to  four  Modules,  in  some  cases, 
adding  equipments,  in  other  cases,  merely  moving  equipments.  Simu- 
lating this  configuration,  the  production  of  the  Image  Based  Pro- 
ducts improved  markedly,  but  throughput  remained  unacceptable. 

Finally,  an  Interactive  Graphics  System  was  substituted  for  one 
of  the  drafting  modules,  an  Analytical  Stereoplotter  Module  was 
added,  and  the  simulation,  again,  re-run.  The  Interactive  Graphics 
had  no  significant  effect  on  drafting  production.  Analysis  revealed 
that  this  was  a result  of  the  assumption  made  that  the  TSS  would  not 
be  provided  with  a digital  data  base. 

The  Analytical  Stereoplotter  significantly  increased  the  Pro- 
duction Rate  of  the  TSS. 


Although  the  simulations  were  equipment-oriented,  detailed 
analysis  of  the  data  indicated  that  some  of  the  remaining  problems 
might  be  due  to  personnel  distributions  and  procedures.  The  July 
1978  configuration  of  the  TSS  will  be  simulated  in  a model  which 
will  allow  re-distribution  of  personnel.  The  results  of  these  simi 
lations  should  show  an  improvement  in  throughput. 
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It  is  concluded  that  the  TSS,  as  currently  configured,  can 
meet  some  quick  response  requests.  With  major  reconfiguration, 
which  would  make  the  TSS  product~or iented , it  should  be  able  to 
meet  all  requests  in  less  than  kS  hours  in  an  intense  combat  en 
vi ronment . 
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1.0  Management  Overview 


I 


The  Topographic  Support  System  (TSS)  is  intended  to  supply  all  of 
the  Army's  requirements  for  topographic  and  military  geographic  infor- 
mation during  a short,  high  intensity  combat  situation.  The  purpose  of 
the  System  Analysis,  which  is  described  in  this  report,  was  to  determine: 

- whether  or  not  the  TSS  had  over  or  under  capacity 
to  locate  "bottlenecks",  (if  any),  in  the  TSS 
which  restrict  production  flow 
to  recommend  solutions  to  problems,  if  any 
were  detected. 

A discrete  events  System  Simulation  Model  was  utilized  as  the  analysis 
tool.  The  language  is  one  that  is  commonly  used  in  the  analysis  of  large- 
scale  assembly  and  production  facilities,  warehousing  operations,  etc. 

A "scenario",  consisting  of  39  different  product  requests,  together 
with  their  frequency  of  occurrence,  priority,  number  of  originals  and 
final  copies,  etc.,  was  generated.  These  product  requests  were  entered 
into  the  TSS  at  the  rate  of  three  per  hour  for  a 144-hour  period,  both 
to  simulate  the  high  intensity  combat  environment  and  also  to  stress  the 
system. 


The  TSS  configuration,  as  of  January  1978,  was  simulated  utilizing 
the  COC  6600  computer.  Under  capacity  was  found  in  Drafting  and  through- 
put problems  were  found  in  the  production  of  products  which  utilize  aerial 
imagery.  Drafting  capacity  was  then  doubled,  and  the  under  capacity  was 
eliminated.  Doubling  of  two  other  Modules,  containing  photo  processing 
type  equipments,  improved  throughput  considerably,  but  did  not  result  in 
achieving  adequate  production  rates. 

Upon  detailed  examination  of  the  results,  it  became  apparent  that  the 
problem  w'th  Inage  Based  Products  resulted  from  intermediate  products  re- 
cycling through  the  same  equipments.  Often  these  equipments  were  located 
in  different  Modules,  further  increasing  delays. 


Minor  modifications  were  made  to  four  Modules,  in  some  cases,  adding 
equipments,  in  other  cases,  merely  moving  equipments.  Simulating  this 
configuration,  the  production  of  the  Image  Based  Products  improved  markedly, 
but  throughput  remained  unacceptable. 

Finally,  an  Interactive  Graphics  System  was  substituted  for  one  of 
the  drafting  modules,  an  Analytical  Stereoplotter  Module  was  added,  and 
the  simulation,  again,  re-run.  The  Interactive  Graphics  had  no  signifi- 
cant effect  on  drafting  production.  Analysis  revealed  that  this  was  a re- 
sult of  the  assumption  made  that  the  TSS  would  not  be  provided  with  a digi- 
tal data  base. 

The  Analytical  Stereoplotter  significantly  increased  the  Production 
Rate  of  the  TSS. 

Although  the  simulations  were  equipment-oriented,  detailed  analysis 
of  the  data  indicated  that  some  of  the  remaining  problems  might  be  due  to 
personnel  distributions  and  procedures.  The  July  1978  configuration  of 
the  TSS  will  be  simulated  in  a model  which  will  allow  re-distribution  of 
personnel.  The  results  of  these  simulations  should  show  an  improvement 
in  throughput. 

It  is  concluded  that  the  TSS  as  currently  configured  can  meet  some 
quick  response  requests.  With  major  reconfiguration,  which  would  make  the 
TSS  product-oriented,  it  should  be  able  to  meet  all  requests  in  less  than 
48  hours  in  an  intense  combat  environment. 
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2.0  Summary 


2. 1 The  TSS 

The  TSS  was  defined  as  a rapid  response  combat  support  system,  con- 
sisting of  the  following  subsystems: 

Operations  which  will  provide  the  administrative  and  operational 
management  of  TSS.  It  will  also  be  the  entry  and  delivery  point 
for  all  requests . 

- The  Storage,  Retrieval  and  Distribution  (SRD)  Subsystem  will  house 
the  data  bank  of  general  and  special  purpose  topographic  information. 
SRD  will  also  maintain  a stockpile  of  finished  products  for  distri- 
bution. The  remaining  five  subsystems  are  operational  elements 
which  will  perform  specific  functions  of  topographic  data  production. 

The  Reproduction  Subsystem  (REPRO)  will  reproduce  the  outputs  in 
the  volume  required  by  the  user.  It  will  a 1 so  reprint  the  stocked 
products  which  become  depleted. 

- The  Cartographic  Revision  (CR)  Subsystem  will  convert  the  manu- 
scripts prepared  by  other  subsystems  into  reproducible  form.  Mew 
data  for  updating  the  graphics  in  the  data  bank  will  be  delivered 
to  CR  for  incorporation  into  manuscripts  or  reproduction  materials. 

The  Survey  Subsystem  (SURVEY)  will  acquire  and  store  coordinate 
and  azimuth  values  for  control  points  required  for  topographic 
support.  It  will  also  have  the  capability  to  determine  coordinates 
■ for  specific  points  identified  by  users. 

i 

The  Image  Base  Products  (IBP)  subsystem  will  perform  all  photo- 
graphic processing  and  transformat  ions  required.  This  includes 
differential  and  frame  rectification,  mosaicking  and  scale  changes 
as  well  as  routine  photographic  reproduction. 


The  Military  Geographic  Information  ( MG  I ) Subsystem  will  be  the 
storehouse  and  center  for  analysis  and  synthesis  for  the  terrain 
intelligence  aspects  of  topographic  support.  The  outputs  will 
range  from  simple  direct  answers  to  specific  questions  through 
graphic  representations  of  terrain  conditions  to  fyll  analyses 
of  terrain  for  specified  military  operations. 

Each  subsystem  consists  of  one  or  more  vans  (Modules)  for  a total  of 
23  Modules  in  the  January,  1978  TSS  configuration  which  was  analyzed. 

2.2  Inputs  to  System  Analysis 

As  will  be  discussed  below,  a General  Purpose  Simulation  System 
(GPSS  V)  computer  model  was  used  for  the  System  Analysis.  In  order  to 
utilize  this  tool,  it  was  necessary  to: 

Develop  a list  of  Products  and  Services  to  be  produced  by  the 
TSS. 

•1 

Manually  prepare  flow  diagrams  of  each  step  performed  in  order 
to  produce  the  Product  or  Service. 


Determine  the  Mean  time  required  to  complete  each  step  in  the 
process  and  variability  of  that  time. 


The  following  paragraphs  summarize  these  activities. 


2.2. 


Product  List 


A review  of  the  Defense  Mapping  Agency  Approved  List  of  Products  and 
Services  revealed  the  general  types  of  output  which  should  be  expected  from 
the  TSS.  It  was  then  necessary  to  prepare  a list  of  spec i f i c products  and 
services.  By  preparing  lists  of  Primary  and  Secondary  categories  of  re- 
quest type,  a list  of  39  different  requests  was  generated. 

Based  not  only  on  past  experience,  but  also  on  the  TSS  capabilities, 
a fixed  percentage  of  each  request  was  then  generated.  For  example,  Pri- 
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mary  Category  1,  "Cartographic  Products  - Single  Level",  occurs  50%  of  all 
requests,  and,  within  that  Primary  Category,  "Overprinted  Standard  Map"  - 
using  overlay  from  MG1  occurs  2%  of  the  50%  or  \%  of  the  total  requests. 
The  entire  Product  List  is  presented  in  Section  3-2.2  of  this  report. 

The  product  list  was  reviewed  by  many  cartographic  and  user  experts. 
No  one  was  able  to  suggest  a better  list,  however,  the  percentage  of  re- 
quests for  Reprints  of  Standard  Maps  was  controversial. 

2.2.2  Product  Attributes 


All  products  were  assigned  attributes,  such  as  Priority,  Number  of 
Originals  required  to  produce  product,  Number  of  Copies  of  Product  required, 
etc.  Associated  with  each  attribute  is  a frequency  of  occurrence.  By 
taking  all  combinations  of  the  39  requests  and  their  attributes  over  20,000 
different  specific  requests  could  occur. 

The  attribute  list  was  also  reviewed  by  many  experts,  and  no  fault 
found . 

2.2.3  Manual  Flow  Diagrams 

For  each  of  the  39  products,  manual  flow  charts  were  prepared  showing 
each  and  every  step  necessary  to  produce  a product  or  service.  The  flow 
charts  for  all  products  occupy  76  pages.  These  flow  charts  and  times  for  two 
TSS  configurations  simulated  are  contained  in  Appendices  A through  G.* 

2.2.k  Task  Timing 

For  each  task  required  in  the  production  of  all  products,  accurate 
time-to-complete  information  was  necessary.  For  many  mundane  tasks,  such 
as  setting  up  a press  and  printing  maps  accurate  information  was  readily 
available  from  sources  such  as  the  Defense  Mapping  School.  However,  for 
many  tasks  of  importance  to  the  TSS,  particularly  in  the  MGI  area,  there 
was  great  variance  in  the  opinion  of  experts  in  the  times  required.  For 


* Interested  readers  may  obtain  copies  of  all  Appendices  from  the 
Engineer  Topographic  Labora tor ies , Attn:  USAETL-TD-SC . 


-5* 


this  reason,  detailed  definitions  of  such  tasks  were  developed,  and  a great 
many  sources  were  contacted  in  an  attempt  to  obtain  a concensus.  In  this 
way,  times  were  finally  developed  and  reviewed  by  personnel  in  a wide  range 
of  agencies.  The  concensus  times  were  found  acceptable  by  all,  and  were 
utilized  in  the  simulation. 

Because  of  the  great  care  devoted  to  tr.a  development  of  accurate 
timing  information,  there  is  no  doubt  that  the  times  used  in  the  simulation 
are  valid  estimates  of  the  real  world  times. 

2 . 3 The  System  Analysis 

The  System  Analysis  was  accomplished  by  means  of  a computer-based 
discrete  system  model.  The  specific  simulation  language  used  was  the 
General  Purpose  Simulation  System  (GPSS  V).  This  system  is  designed  to 
develop  statistics  on  utilization  of  equipment  and  personnel,  lengths  of 
times  required  to  produce  products,  lengths  of  times  spent  waiting  for 
available  equipment,  etc.  It  is  frequently  used  to  determine  the  number 
of  equipments  need  in  manufacturing,  assembly  or  warehousing  operations. 

The  model  is  described  in  detail  in  Section  4 of  this  report.  The 
following,  however,  illustrates  the  system  model  capabilities.  In  the 
simulations  reported  herein,  one  of  the  39  requests  was  chosen,  utilizing 
one  random  number  generator  to  select  a Primary  Category,  and  a second  to 
select  the  Secondary  Category.  That  request  then  entered  the  Operations 
Module  for  processing.  8ased  upon  the  request  category  and  attributes, 
a Route  Control  Generator  "told"  the  request  where  to  go  next.  For  example, 
if  the  request  could  be  met  by  merely  retrieving  a Standard  Map,  the  re- 
quest was  routed  to  SRD. 

Within  each  Module  a similar  Route  Control  Generator  "moved"  the  re- 
quest about.  Continuing  the  simple  example  of  a Standard  Map,  a server 
in  the  Distribution  Moaule  would  utilize  the  Rolodex  file  for  a time  sampled 
from  a distribution  of  times  required  to  locate  the  required  map.  Having 
found  the  location,  another  distribution  of  times  would  be  used  to  deter- 
mine the  length  of  time  required  to  retrieve  it,  etc.  The  times  required, 
of  course,  are  modulated  by  the  attributes,  such  as  number  of  originals,  etc. 
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If  a request  arrived  in  Distribution  while  all  personnel  were  otherwise 
occupied,  or,  for  example,  the  Rolodex  was  being  used,  the  request  would 
have  to  wait  in  a queue.  Whenever  a queue  developed,  the  highest  priority 
requests  took  precedence  in  line  to  the  high  priority,  which,  in  turn, 
went  ahead  of  the  normal  priority. 

I The  example  of  a retrieval  of  a Standard  Map  is,  of  course,  simplistic. 

In  the  production  of  more  complicated  products,  very  much  longer  times  are 
required,  as,  for  example,  in  cartograph ica 1 1 y enhancing  MGI.  It  is  obvious 
that  any  "bottlenecks"  in  the  TSS  would  be  detected  where  high  queues 
developed  in  any  area,  Drafting,  for  example. 

Because  the  TSS  was  built  up  from  an  overall  model  of  it,  down  to  the 
models  of  the  Modules  and  then  to  models  of  the  individual  equipments,  it 
is  completely  flexible.  That  is,  where  any  queue  developed,  capacity  could 
be  added,  and  the  simulation  run  again  until  the  problem  was  solved.  This 
is  how  recommendations  were  developed  to  solve  problems  of  undercapacity. 

2.4  Results 


The  TSS  configuration  as  of  January  1978  was  simulated  at  a request 
rate  of  three  per  hour.  Two  twelve-hour  shifts  were  simulated  for  144  hours 
or  six  days.  Two  areas  of  undercapacity  were  detected.  One  was  the  Draft- 
ing Module,  while  the  other  involved  several  modules  used  in  the  production 
of  Image  Based  Products  combined  with  the  preparation  of  Synthesized  MGI. 

At  the  end  of  1 44  hours.  Drafting  had  completed  only  11  jobs,  averaging 
18.5  hours  per  job.  There  was  a queue  of  21  jobs  waiting  for  drafting.  The 
simulation  was  then  run  again  with  two  Drafting  Modules.  Not  unexpectedly, 

22  jobs  were  completed,  each  averaging  about  18.4  hours.  However,  the 
queue  was  dramatically  reduced  to  only  6 jobs  waiting.  There  was,  however, 
underutilization  of  the  drafting  tables  in  Drafting  when  Drafting  was  doubled 
Further  analysis  revealed  that  this  was  due  to  understaffing  in  Drafting. 

By  increasing  the  number  of  draftsmen,  this  problem  is  eliminated. 
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Average  utilizations  of  the  Light  Table  in  Synthesis,  the  Automatic 
Film  Processor  in  Rectifier  I,  and  APPS  in  Rectifier  II,  the  Photo  Processing 
Machine  in  Photomechanical,  and  the  Copy  Camera  in  Camera  ranged  from  67  to 
96%.  Queue  lengths  ranged  from  II  to  21,  except  for  the  Copy  Camera  which 
had  a queue  of  55. 

Again,  the  simulation  was  then  run  again,  simply  doubling  Rectifier  I 
and  Camera,  which  appeared  to  be  causing  the  bottleneck.  Although  the  num- 
ber of  completed  products  was  up  sharply,  queue  lengths  did  not  decrease 
significantly.  Further  analysis  revealed  that  this  was  due  to  the  re- 
cycling of  several  intermediate  products  through  the  various  photoprocessing 
equipments.  For  example,  an  Uncontrolled  Photomosaic  cycles  six  times 
through  the  Printer/Enlarger,  the  Automatic  Film  Processor  and  the  Copy 
Camera  to  produce  negatives,  wrong  reading  positives,  positives,  etc. 


For  this  reason,  a slight  reconfiguration  of  the  TSS  was  introduced. 
One  Light  Table  was  added  to  Synthesis;  an  Automatic  Film  Processor,  a 
Printer/Enlarger  and  a Copy  Camera  were  added  to  Rectifier  II;  and  a 
Printer/Enlarger  and  an  Automatic  Film  Processor  were  added  to  Camera. 

It  was  determined  that  these  equipments  fit  in  the  Modules. 


The  simulation  was  then  run  again.  All  queues,  except  the  photopro- 
cessing machine  in  Photomechanical  and  the  Copy  Camera  in  Camera  went  to 
zero.  The  number  of  Single  Level  Photographic  Products  completed  went 
from  zero  to  38.7%  of  an  Expected  Value  of  60%,  based  on  a no  queue  situa- 
tion. 


In  addition,  the  same  TSS  configuration  was  simulated,  substituting 
an  Interactive  Graphics  System  for  one  of  the  two  Drafting  Modules  and 
adding  an  Analytical  Stereoplotter  to  Orthophoto.  The  Interactive  Graphics 
did  not  affect  throughput.  It  was  assumed  that  no  digital  data  base  was 
available.  If  this  assumption  is  incorrect,  the  Interactive  Graphics  might 
increase  throughput.  The  Analytical  Stereoplotter  resulted  in  significant 
increases  in  Production. 

The  GPSS  Report  Generator  Computer  Output  for  the  four  conf i gurat ions 
simulated  are  contained  in  Appendix  H-l  through  H-4. 
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It  is  concluded  that,  with  reconfiguration  of  equipment  and  personnel 
above  and  beyond  that  already  accomplished,  the  TSS  would  have  a quick 
reaction  capability  in  a high  intensity  combat  situation.  Additional 
simulation  should  be  accomplished  to  determine  the  required  reconfigur- 
ation. 
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3.0  TSS  Procedures  and  Flow 


3.1  Data  Gather i ng 

Data  gathering  was  preceding  by  study  and  discussion  aimed  at 
"fixing"  TSS  operational  philosophy.  This  activity  resulted  in  the 
following  general  conclusions: 

* The  major  portion  of  TSS  capacity  will  likely  be  devoted 
to  the  preparation  of  special  purpose  MG  I products; 

* To  meet  anticipated  time  constraints,  already  available 
MGI  factor  overlays  are  a virtual  necessity; 

* Time  restrictions  in  the  combat  environment  preclude  the 
preparation  of  output  products  as  elaborate  as  those  pro- 
duced in  the  peacetime  base  plant  or  garrison  type  environ- 
ments'; and 

* Since  no  means  are  provided  to  allow  utilization  of  panor- 
amic aerial  photography  in  the  compilation  of  line  maps 
and  orthogonal  photographs,  such  photography  will  be  used 
solely  in  the  production  of  photomosaics,  to  the  extent 
practicable. 

Data  gathering  included  determination  of  the  following: 

* Procedures  and  production  flow  for  all  anticipated  TSS  pro- 
ducts ; 

* Estimates  of  the  average  time(s)  to  complete  each  manual 
function,  the  times  expressed  in  either  man-hours  or  total 
hours  based  on  the  manning  figure  established  for  the  parti 
cular  module(s)  under  consideration; 

* Estimates  of  the  average  machine  and/or  man/machine  time(s) 
as  applicable  to  the  function(s)  under  consideration;  and 


* Estimated  equipment  downtime. 


3.1.1  Procedures 

Data  gathering  procedures  included:  personal  interviews  and  dis- 
cussions with  recognized  experts  in  the  various  mapping  functional  areas 
applicable  to  TSS;  review  of  available  documentation,  including  pertin- 
ent U.  S.  Army  training  manuals,  personnel  proficiency  criteria,  manu- 
facturer’s documentation  and  technical  studies;  inspection  of  equipments; 
and  observation  of  both  manual  and  man/machine  operations.  In  virtually 
all  instances,  the  average  estimated  times  derived  from  these  procedures, 
either  individually  or  in  combination,  were  based  upon  the  expert  opinions 
of  several  individuals. 

In  the  areas  of  map  compilation  and  special  purpose  MGI  product 
synthesis  it  was  deemed  appropriate  to  think  in  terms  of  a hypothetical 
"average"  1:50,000  scale  map  sheet  area  (i.e.  an  area  of  "average" 

: . di ff icul ty'in  terms  of  terrain  and  cultural  detail)  as  well  as  a pro- 

duct treatment  commensurate  with  the  demanding  48-hour  maximum  TSS  pro- 
duct turnaround  time.  The  alternative  would  have  been  to  create  an  in- 
dividual scenario  for  each  product  considered  in  the  computer  simulation. 
This  in  turn,  would  have  reduced  the  total  number  of  products  processed 
through  the  computer  model  to  the  point  where  "stressing"  the  system 
would  not  have  been  possible. 

3-1.2  Organ i za t ions  Contacted 

The  following  is  a tabulation  of  the  organizations  contacted  in 
connection  with  each  TSS  subsystem: 

Command  and  Control  (Operations) 

* Department  of  Cartography,  DMS 

* Systems  Concept  and  Definition  Division,  Topographic 

Developments  Laboratory,  ETL 

Storage,  Retrieval  and  Distribution 

* Mapping  Development  Division,  Topographic  Developments 
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* Systems  Concept  and  Definition  Division,  Topographic  Develop- 
ments Laboratory,  ETL 

Reproduction 

* Department  of  Graphic  Arts,  DMS 

* 30th  Engineer  Bn.  (T) (A) 

* Surveying  and  Engineering  Division,  Topographic  Developments 
Laboratory,  ETL 

Cartographic  Revision 

* Department  of  Cartography,  DMS 

* 30th  Engineer  Bn.  (T) (A) 

Survey 

* Surveying  and  Engineering  Division,  Topographic  Developments 
Laboratory,  ETL 

* Systems  Concept  and  Definition  Division,  Topographic  Develop-^ 
ments  Laboratory,  ETL 

* Department  of  Cartography,  DMS 

Image  Base  Products 

* Systems  Concept  and  Definition  Division,  Topographic  Develop- 
ments Laboratory,  ETL 

* Department  of  Cartography,  DMS 

Military  Geographic  Information 

* Terrain  Analysis  Center,  ETL 

* Applications  and  Systems  Division,  Geographic  Sciences  Laboratory, 
ETL 

* Data,  Products  and  Processing  Division,  Geographic  Sciences 
Laboratory,  ETL 

* Department  of  Topographic  Sciences,  DMS 

* 30th  Engineer  Bn.  (T) (A) 

* 64th  Engineer  Detachment  (Terrain) 
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3.1.3  Oi ff icul ties  I 

At  the  outset  of  discussions  in  a number  of  instances,  the  expert(s) 
consulted  found  it  difficult  to  relate  to  and,  therefore,  make  production 
timing  commitments  for  an  "average"  map  area  product  destined  to  receive 
product  treatment  in  line  with  the  short  maximum  turnaround  time  demanded 
by  TSS  in  the  combat  environment.  This  was  particularly  true  in  connection 
with  the  synthesis,  compilation  and  drafting  of  the  special  purpose  MG  I 
products  and,  to  a lesser  degree,  with  regard  to  the  processing  of  incoming 
user  requests.  This  difficulty  is  understandable  and  was  to  be  expected, 
since  many  of  the  available  experts  had  been  engaged  in  peace-time  base 
plant  and/or  garrison  type  operations  throughout  the  recent  past,  where 
production  time  estimates  are  based  on  the  anticipated  level  of  difficulty 
of  each  individual  map  product,  and  time  is  generally  not  as  critical  as  in 
the  tactical  situation.  This  difficulty  was  overcome  through  a great  deal 
of  discussion. 

Considerable  difficulty  was  also  encountered  in  the  area  of  equipment 
reliability.  Investigation  revealed  that  mean  time  between  failure  (MTBF) 
and  mean  time  to  repair  (MTR)  per  se  was  unavailable  for  both  already 
fielded  equipment  and  new  equipment.  It  was  found  that  annual  maintenance 
man-hour  data  was  available  on  most  of  the  conventional  equipment  and  this, 
coupled  with  estimates  based  on  manufacturers  documentation  on  "new" 
equipment,  was  used  to  predict  equipment  reliability. 

3.1.4  Resul ts 

Because  of  the  procedures  used  in  gathering  the  required  data,  and 
the  considerable  amount  of  time  and  effort  devoted  to  this  activity,  it 
is  felt  that  the  results  are  quite  reliable.  The  most  reliable  estimates 
are  undoubtedly  those  which  relate  to  reproduction  activities,  since  these 
activities  are  quite  independent  of  the  type  of  area  mapped.  Probably 
the  least  reliable  are  those  estimates  related  to  MG  I special  purpose 
product  synthesis,  comoilation  and  drafting  since  these  activities  are 
somewhat  new  and  unique  to  TSS. 


3-2  TSS  Production  Assumptions 

In  building  any  model  of  a real  system,  it  is  necessary  to  make 
assumptions  regarding  the  operation  of  that  system  in  the  real  world. 

The  results  of  exercising  the  model  can  be  no  better  than  the  under- 
lying assumptions. 

In  the  formulation  of  the  computer  simulation  of  the  TSS,  certain 
reasonable  and  basic  assumptions  were  made.  These  assumptions  are: 

* A product  request  begins  and  ends  in  the  CSC  Operations 
module.  When  a product  request  enters  C S C,  a server  will 
plan  the  job  or  will  give  a verbal  explanation  to  the  custo- 
mer as  a product.  When  a requested  product  is  completed, 
this  product  is  inspected  and  then  distributed  at  C S C. 

Thus,  times  to  process  requests  from  the  user  to  the  TSS 
and  times  to  deliver  the  product  to  the  ultimate  user  are 
not  included. 

* Production  routing  of  products  through  the  TSS  is  done 
sequentially.  This  is  to  say,  tasks  are  performed  on  a 
product  one  at  a time  in  an  ordered  sequence  instead  of 
performing  two  or  more  tasks  on  a product  concurrently. 

Also,  a product  is  not  divided  into  separate  parts  to  be 
worked  on  in  different  vans.  A product,  including  its 
parts,  always  remains  together  and  is  sent  to  one  van  at 
a time. 

* The  environment  in  which  the  TSS  is  to  operate  is  the  SCORES  (Europe) 
scenario,  as  opposed  to  operating  in  a peacetime-garrison  mode. 

This  impacts  the  quality  level  of  certain  products  because 
production  times  must  not  be  excessive.  Thus  certain  synthe- 
sis, compilation,  and  manual  drafting  procedures  in  MG  I and 
Cartographic  Revision  reflect  a product  of  less  than  excellent 
cartographic  quality  but  of  much  lower  production  time.  This 

quick  response  is  appropriate  for  the  SCORES  scenario. 
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* SRD,  REPRO,  and  IBP  functions  are  "equipment"  oriented  while 
seemingly  the  functions  of  CR  and  MGl  are  "process"  oriented. 

In  order  to  make  the  simulation  consistent  throughout  the  TSS, 

CR  and  MGl  are  modelled  in  an  equipment  oriented  manner.  That 
is,  to  perform  a CR  or  MGl  function,  certain  equipments  are 
"lumped"  together  and  assigned  to  that  function.  Then,  a 
specified  amount  of  time  is  spent  at  each  piece  of  equipment, 
thus  partitioning  a function  or  process  into  discrete  tasks 

at  the  equipment  level.  This  allows  all  the  subsystems  to  be 
modelled  in  the  same  equipment  oriented  manner. 

* The  return  of  repromats  back  to  SRD  from  other  TSS  elements 

is  assumed  to  be  background  activity.  Also,  repromats  stocked 
in  the  TSS  are  assumed  to  be  available  for  use  at  any  time 
without  delay  due  to  their  usage  elsewhere  in  the  system. 

* When  a product  fails  inspection  in  the  C & C Operations  module 
at  the*end  of  its  production  sequence,  it  recycles  its  entire 
production  route  once  more. 

* The  time  needed  for  frequent  in-process  inspections  of  a 
product  is  integral  with  the  time  used  to  perform  the  job 
on  the  various  equipments. 

* When  a scribe  coat  is  used  during  the  production  of  a product, 
the  application  of  a photosensitive  coating  to  the  scribe 
coat  is  included  as  part  of  the  scribe  coat  preparation  pro- 
cess. 

* In  the  Rectifier  I module,  both  film  processing  and  rectifi- 
cation functions  can  occur  at  the  same  time  because  the  darkroom 
facilities  are  segregated  from  the  rest  of  the  module  by  curtains. 
Thus  the  use  of  the  darkroom  facilities  does  not  preempt  or  inter- 
fere with  the  use  of  the  rectifying  equipment. 
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* Although  MGl  personnel  are  cross-t ra i ned  and  supposedly  able 
to  move  from  module  to  module  as  the  workload  dictates,  in  the 
simulation  the  MG  I personnel  remain  in  the  module  to  which  they 
are  assigned.  In  the  real  world,  they  would  be  available  to 
backup  other  functions  only  when  they  are  not  otherwise  occupied. 

* In  the  Press  modules,  "driers"  are  incorporated  in  the  ink 
so  that  the  drying  time  of  printed  products  is  reduced. 

* The  TSS  is  initially  supplied  with  a full  complement  of  factor 
overlays.  Additional  factor  overlays  reflecting  changes  due 
to  the  effects  of  combat  are  produced  in  MGI. 

* The  production  status  board  is  to  be  used  to  record  and  post 
the  present  status/progress  of  the  product  requests  currently 
being  processing  in  the  TSS. 

* The  IBM  card  punch  is  to  be  used  to  update  the  TSS  inventory 
when  materials  such  as  standard  maps  are  withdrawn  from  the 
TSS  stock. 

* Telephone  (or  equivalent)  communications  exists  between  all 
modules. 

! 

* Power,  water,  and  supplies  will  be  available  to  the  TSS  at  all 
t i mes . 

* With  respect  to  the  Interactive  Graphics  System,  it  is  assumed 
that  no  CONUS-prepared  digital  data  base  exists  in  the  TSS. 

* An  APPS  Data  Base  exists  for  the  entire  area  of  coverage  of 
the  TSS. 

* The  Corps  Level  TSS  configuration  is  used.  This  complete,  23 
module  Corps  Level  TSS  is  positioned  with  a Mean  of  120  meters 
separation  between  vans. 


* The  request  rate  for  TSS  products  is  three  requests  per  hour. 

This  request  rate  will  stress  the  TSS's  production  capability, 
allowing  any  "bottlenecks"  in  the  system  to  be  identified. 

* Personnel  efficiency  will  be  constant,  not  degraded  during  a 
shi ft. 

* Two  twelve-hour  shifts  per  day  were  simulated.  No  degradation 
in  TSS  performance  was  assumed  as  a function  of  changing  shifts. 
That  is,  each  person,  when  beginning  a shift  was  assumed  to 
continue  the  work  of  the  person  he  replaced  without  any  interrup- 
tion. 

* Where  alternate  paths  are  available  for  the  production  of  a pro- 
duct, the  simulation  logic  "looked  ahead"  to  determine  which 
path  would  result  in  the  earliest  completion  of  the  task(s). 

The  product  was  then  routed  to  fastest  path.  This  simulates 
an  unerring  management. 

* All  repromats  delivered  to  the  TSS  will  originally  be  film  posi- 
tives. As  negatives  are  made,  they  will  be  saved  as  intermediate 
products . 


3-3  Product  List 


n 


The  product  list  contains  the  products  which  can  be  produced  by 
the  TSS  in  this  simulation.  This  list  is  the  result  of  careful  study 
of  the  DMA  List  of  Approved  Products  and  of  consultation  with  ETL  con- 
cerning products  that  the  TSS  would  be  capable  of  producing.  Along 
with  the  listed  products  are  their  percentages  of  occurrunces  and  asso- 
ciated attributes.  The  percentage  of  occurrence  for  each  product  coin- 
cides with  the  expected  user  demand  for  that  product. 

The  product  attributes  describe  the  product's  priority  level  and 
the  number  of  copies  of  the  product  to  be  produced.  The  product  attri- 
butes and  their  percentages  of  occurrence  are  listed  at  the  end  of  the 
product  list. 

The  completed  product  list  and  its  associated  attributes  list  was 
reviewed  by  ETL  and  jDther  agencies  and  was  found  to  be  satisfactory. 


i 
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Per  Cent 


Product  - Primary  Category 

Occurrence 

(1)  Cartographic  Products  - 

Single  Level 

50 

(2)  Cartographic  Products  - 

Mul t i -Level 

15 

(3)  Photographic  Products  - 

Single  Level 

8 

(4)  Photographic  Products  - 

Multi -Level 

5 

(5)  Verbal  Information  - 

and/or  Explanation 

4 

(6)  Textual  Information  - 

2 

(7)  Bound  Volume  Information  - 

4 

(8)  Special  Print  Request  - 

12 

r 


Product  - Primary  Category  #1 


Cartographic  Products  - Single  Level 


Product  - Secondary  Category 

(1)  Standard  Map  - 

(2)  Overprinted  Standard  Map  - 

Using  overlay  from  SRD 

(3)  Overprinted  Standard  Map  - 

Using  overlay  from  MG l 

(4)  Overprinted  Standard  Map  - 

Using  special  MGI  overlay 
(ie.  Helicopter  Landing 
Zones) 

(5)  Overprinted  Standard  Map  - 

Using  special  MGI  overlay 
(ie.  Cross  Country  Move- 
ment) 

(6)  Non-Standard  Map  - scale  change 

(7)  Non-Standard  Map  - scale  change 

£ selective  omissions 
(ie.  contours  omitted) 


Per  Cent 
Occurrence 


Associated 
Att  r i butes 


A.B.C 


A.C.D 


A.C.D 


A, C , D 


A , C , D 


A , C , D 


A , C , D 


r’ 


Product  - Primary  Category  HI 


C^rt^rap^^JVo^uc^^^Jl^^i^Leve^ 


Product  - Secondary  Category 


(1)  Standard  Map  - Single  overlay 
obtained  from  SRD 


(2)  Standard  Map  - Single  overlay 
comp i 1 ed  in  MG  I 


(3) 


Standard  Map  - Four  factor 
overlays  obtained  from  SRD 
S interpretation  performed 
in  MG1 


W 


Standard  Map  - Four  factor 
overlays  obtained  from  SRD, 
interpretation  performed  in 
MG  1 , 6 cartographic  enhance- 
ment in  CR 


(5)  Standard  Map  - With  special 

MG  I overlay  (ie.  Helicopter 
Landing  Zones) 


(6) 


Standard  Map  - With  special 
MGI  overlay  (ie.  Cross 
Country  Movement) 


(7)  Non-Standard  Map  - Scale  change, 
MGI  overlay  with  information, 
and  compilation  in  CR 


Per  Cent 
Occurrence 


10 


50 


15 


10 


Assoc iated 
Attr i butes 


A,C,D 


A.C.D 


A , C , D 


A , C , D 


A , C , D 


A ,C , D 


A , C , D 
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Assoc i ated 
Attri butes 


(1)  Standard  Photos  - Using 

unrectified  frame  photo- 
graphs (9"x9"  format)  9 A,C,D 

(2)  Standard  Photos  - Using 

unrectified  3"  panoramic 

photographs  3 A,C,D 


(3)  Uncontrolled  Photomosaic  - 
Standard  map  size  using 

9"x9"  frame  photography  10  A,C,D,E 


(4)  Orthophoto  Mosaic  - Controlled 
photomosaic  of  a standard 
map  area  using  frame  photo- 
graphy 20  A,C,D,E 


(5)  Controlled  Photomosiac  - 

Standard  map  size  "using 

9"x9"  frame  photography  12  A,C,D,E 

(6)  Special  Enlarged  Photo  - 

Photographically  annotated 

with  information  from  MG  I 12  A,C,D 

(7)  Photos  with  control  points  - 

Manually  annotated  hori- 
zontal control  points, 

9"x9"  format  including  APPS 

position  coordinates  12  A,C,D 
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Photos  with  control  points  - 
photographically  annotated 
horizontal  control  points, 
9"x9"  format  including  APPS 
position  coordinates,  also 
with  MG  I annotat ion 


12 


A,C,0 


(9)  Uncontrolled  Photomasaic  - 

Using  unrectified  panoramic 
photos 


10 


A.C.D.E 


Product  - Primary  Category  ttk 


^hoto^aphj^c^^Productj^^Mi^U^Lev^ 


Product  - Secondary  Category 

(1)  Standard  Photo  Map  * 

Single  overlay  obtained 
from  SRD 

(2)  Standard  Photo  Map  - 

Single  overlay  obtained 
from  MG  I 

(3)  Standard  Photo  Map  - 

Single  overlay  obtained 
from  SRD  & interpretation 
performed  in  MG  I 

((♦)  Standard  Photo  Map  - 

Single  overlay  obtained 
from  SRD  & two  overlays 
from  MG  I 


Per  Cent 
Occurrence 


20 


20 


20 


10 


(5)  Standard  Photo  Map  - 

Single  overlay  obtained 
from  SRD,  two  overlays 
obtained  from  MG  I & inter- 
pretation performed  by  MGI  10 

(6)  Non-Standard  Photo  Map  - 

Using  overlay  information 
from  MGI  & drafting  per- 
formed by  CR  10 

(7)  Standard  Photo  Map  - 

Using  overlay  information 

obtained  from  MGI  S drafting 

performed  by  CR  10 
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Assoc i ated 
Attr i butes 


A.C.D 


A.C.D 


A.C.D 


A.C.D 


A.C.D 


A,  C , D 


A.C.D 


Verbal  Information  and/or  Ex 


This  category  is  slightly  different  than  those  previously 
mentioned.  This  category  was  designed  to  simulate  an  activity 
that  would  occur  in  the  Operations  Module.  Namely,  the  distri- 
bution of  verbal  information  to  a "customer". 


Since  the  standard  analysis  of  conversation  length  has 
been  found  to  be  well  represented  by  an  exponential  distri- 
bution, we  have  selected  such  a distribution  with  a mean  value 
of  15  minutes  to  represent  the  transmission  of  information 
verba  I 1 y . 


Textual  Information 


Product  - Secondary  Category 


Per  Cent 
Occurrence 


(1)  Standard  Bulletin  - 

Retrieved  from  SRD  50 


(2) 

Standard  Trig.  List  - 

20 

(3) 

Special  Report  - 

Special  5-page  report 

prepared  by  MG  1 

30 

Assoc i ated 
A 1 1 r i butes 


A.B.C 
A , B , C 
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Product  * Primary  Cateqory  #7 

1 

Bound  Volume  Information 

Product  - Secondary  Cateqory 

Per  Cent 
Occurrence 

Assoc i ated 

Attr i butes 

(1)  Standard  Maps  - reduce 

scale,  8i"xl 1"  format 

(2)  Standard  Maps  - reduce 

scale,  8*"xll"  format, 
including  point  position 
detai 1 and  trig,  1 i sts 

(3)  Standard  Maps  - reduce 

scale,  8i"'xll"  format, 
special  purpose  overlay 
and  text  from  MG  I 


40  A.C.D 


25  A.C.D 


35  A, C , D 


J 


r ’ 


Product  - Primary  Category  #8 


Special  Print  Request 


Product  - Secondary  Category 


Per  Cent 
Occurrence 


Assoc iated 
Attr i butes 


(1)  Standard  Map  - produce 
1000  copies  of  a map 
using  repromat  from  SRD 


75 


(2)  Standard  Map  - produce 
1000  copies  of  a map 
with  revisions 


25 


Attribute  Definitions 


ATTRIBUTE  A:  This  attribute  represents  the  desired  number  of  different 

basic  items  of  a particular  nature,  in  a specific  Secondary 
Category,  per  specific  request.  For  example,  (1)  Four 
Standard  Maps,  each  of  which  describes  four  different,  but 
perhaps  adjacent,  topographic  areas.  (2)  Three  Standard 
Photo  Maps,  each  of  which  depicts  three  different,  but  per- 
haps adjacent,  topographic  areas.  (3)  Two  Standard  Military 
Bulletins,  which  consist  of  the  most  recent  and  the  one  pre- 
viously issued.  This  attribute  can  take  on  the  value  in 
the  following  table: 


Number  of 

Per  Cent 

Basic  Items 

Occurrence 

ONE  (1) 

75  ' 

FOUR  (A) 

10 

SIXTEEN  (16) 

15 

ATTRIBUTE  B:  This  attribute  represents  the  desired  number  of  originals  of 
each  of  the  different  basic  items  of  a particular  nature,  in 
a specific  request.  This  attribute  applies  only  to  those 
basic  items  that  are  distributed  to  "customers"  in  original 
form.  For  example:  (1)  Standard  Maps,  (2)  Bulletins,  (3) 
Trig.  Lists,  are  all  simply  retrieved  from  files  and  distri- 
buted. This  attribute  can  take  on  the  values  in  the  follow- 
ing table: 


Number  of 

Per  Cent 

Originals 

Occurrence 

ONE  (1) 

80 

FOUR  (4) 

12 

SIXTEEN  (16) 

5 

HUNDRED  (100) 

3 

j 
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ATTRIBUTE  C:  This  attribute  represents  the  level  of  priority  of  the 
request  it  is  associated  with.  Each  of  the  priority 
levels  will  impact  the  service  times  and  waiting  times 
associated  with  the  current  transaction.  Priority  level 
will  also  affect  the  speed  with  which  certain  TSS  per- 
sonnel perform  their  duties.  This  attribute  can  take  on 
the  values  in  the  following  table: 


Level  of 

Per  Cent 

Priori ty 

Occurrence 

NORMAL  (0) 

5 

MEDIUM  (1) 

85 

HIGH  (2) 

10 

ATTRIBUTE  D:  This  attribute  represents  the  desired  number  of  copies  of 
a product  resulting  form  a TSS  processing  action  other 
than  just  pure  retr ieva 1 /d i st r i but i on . This  attribute 
differs  from  ATTRIBUTE  (B)  in  that  it  applies  to  all  items 
exclusive  of  those  that  ATTRIBUTE  (A)  encompasses.  This 
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ATTRIBUTE  E:  This  attribute  represents  the  number  of  frames  to  be 

rectified  in  the  process  of  making  a Photomosaic.  This 
attribute  can  take  on  the  values  in  the  following  table: 


3.^*  Analysis  of  Image  Based  Product  Requirements  in  the  TSS 


The  objectives  of  this  effort  were  as  follows: 

1.  To  acquire  user  input  as  to  the  need  for  image  base  products 
in  the  tactical  environment  and,  thereby,  verify  to  the  ex- 
tent possible,  the  assumptions  made  by  DEC  I LOG  concerning  the 
frequency  of  requests  for  these  products  as  used  in  the  TSS 
computer  simulation;  and 

2.  To  specifically  review  the  need  for  TSS  production  of  ortho- 
gonal photography,  since  the  production  of  such  products  in 
the  TSS  environment  presents  somewhat  complex  technical  pro- 
blems in  the  areas  of  both  source  input  (ie.  aerial  photo- 
graphy) and  processing  instrumentation. 

The  orthophoto  technical  problems  relate  to  the  fact(s)  that:  the  analog 
equipment,  originally  anticipated  for  integration  into  TSS  and  likely  capable 
of  withstanding  the  harsh  physical  environment,  requires  mapping  quality, 
vertical  aerial  photography  (ie.  photography  of  high  geometric  fidelity); 
while  the  analytical  orthophoto  equipment,  subsequently  proposed  and  some- 
what more  susceptable  - in  its  commercially  available  form  - to  damage  in 
the  TSS  environment,  is  capable  of  utilizing  both  mapping  quality  photo- 
graphy and  reconnaissance  photography. 

During  the  course  of  the  study,  meetings  were  held  with  the  following 
organ i zat i ous : 

- Assistant  Chief  of  Staff  for  Intelligence  (ACSI),  U.  S.  Army 
Requirements  Division,  Directorate  of  Plans  and  Requirements, 

Defense  Mapping  Agency  Topographic  Center  (DMATC) 

- Technical  Director,  Defense  Mapping  School 

- U.  S.  Army  Engineers  School 

- U.  S.  Army  Combined  Arms  Combat  Development  Activity  (CACDA) 
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In  addition,  the  GIANT-75  study  was  carefully  reviewed  to  determine 
what,  if  any,  j us t i f i ca t ion (s)  was/were  used  in  formulating  the  recommen- 
dations for  TSS-produced  image  base  products,  particularly  orthogonal 
photographs . 

During  the  above  meetings,  the  assumptions  used  by  DEC  I LOG  in  its 
TSS  model  simulation  - with  regard  to  the  types  and  percentages  of  image 
base  products  - were  discussed,  and  the  participants  were  asked  to  express 
their  views  as  to  the  reasonableness  (or  lack  thereof)  of  DECILOG's  assump- 
tions. The  following  products  were  reviewed: 

Individual  Photographs  (Vertical) 

2x  Enlargement 

Standard  Map  - Size  Enlargement 
Individual  Pnotographs  (Panoramic) 

2x  Enlargement 

Standard  Map  - Size  Enlargement 
Photomosaic 
Uncontrol  led 
Control  led 

Orthogonal  Photograph 
Photomap 

Using  Controlled  Photomosaic 
Using  Orthophotomosaic 

In  all  cases,  an  attempt  was  made  to  identify  the  user  of  the  product, 
the  purpose  or  use  of  the  product,  and  the  alternative  product  if  the  image 
based  product  was  not  available. 

Review  of  the  GIANT-75  study  did  not  reveal  the  existence  of  any  hard 
justification  for  TSS  production  of  orthogonal  photographs.  It  did  indi- 
cate that:  "contoured  orthophotographs  produced  with  a combination  of  these 
devices  (ie.  Kelsh  Plotter/SFOM  693  orthophotographic  unit)  and  cartographic 
quality  photography  can  be  the  base  for  multi-scaled  graphics  for  many 
planning  and  operational  purposes.  However,  compilation  is  slow  and  depen- 
dent on  the  availability  of  suitable  photography."  The  study  recommended 
incorporation  of  a modified  van  body  to  accommodate  this  type  (ie.  ortho- 
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photo)  equipment.  The  study  also  noted  that: 

1.  The  enhanced  photomap  is  produced  faster  than  the  conventional 
1 i ne  map ; 

2.  Photomap  production  requires  the  availability  of  new  (ie.  current) 
photography ; 

3.  Since  requirements  for  cartographic  quality  photography  are 
secondary  to  the  requirements  for  reconna i ssance  photography, 
it  is  doubtful  that  suitable  photography  will  be  available  for 
photomap  revision  under  battle  conditions;  and 

A.  Therefore,  it  is  adviseable  to  standardize  on  the  line  map 
vice  photomap. 

The  discussions  revealed  that  the  primary  value  of  the  image  based 
products  (particularly  orthogonal  photographs)  was  as  an  expedient.  In 
no  case  was  it  found  that  these  products  were  an  absolute  necessity.  Most 
users  indicated  that  the  image  based  products  were  an  important  and  highly 
desireable  adjunct  to  the  line  map  products.  All  indicated  that  the  con- 
trolled photomosaic  was  of  equal  value  to  the  orthophotomosaic. 

Discussions  as  to  the  types  and  percentages  of  image  based  products 
used  by  DECILOG  in  its  TSS  computer  simulation  revealed  only  minor  dis- 
agreement in  a few  cases  by  the  user.  In  all  such  instances,  the  user  in- 
volved indicated  that  he  had  no  better  basis  for  his  estimate  than  did 
DECILOG. 

Additionally,  CACDA  user  personnel  stressed  the  fact  that  maps  will, 
in  the  future,  be  used  only  for  mobility  purposes.  Artillery  will  utilize 
advanced  hardware  such  as  FIREFINDER  and  PADS  for  precision  targeting. 
Infantry  and  Armor  will  similarly  rely  on  laser  designators  and  the  Position 
Location  and  Reporting  System.  Even  Intelligence  will  require  that  all 
mobile  direction  finding  and  other  listening  systems  will  require  on  boa rd 
Posi tion/Locat ion  hardware. 
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During  recent  discussions  one  user  group  suggested  that  orthophoto 
city  maps  might  be  an  expedient  substitute  for  the  line  maps  needed  in 
connection  with  Mobility  Operations  in  Built-up  Areas  (MOBA) . A second 
suggested  orthophoto  application  was  in  the  mapping  of  areas  devastated 
by  nuclear  attack. 


City  Maps  - One  of  the  problems  encountered  in  the  use  of  aerial  photography 
in  mapping  built-up  areas  is  the  shielding  of  detail  located  in  the  shadows 
(ie.  layback  areas)  of  buildings,  trees,  etc.,  which  are  not  located  at,  or 
closely  adjacent  to,  the  photo  center.  In  conventional  photogrammetr i c 
mapping  this  is  overcome  by  extracting  the  desired  planimetric  and  topo- 
graphic detail  while  viewing  a stereo  model.  During  the  compilation  of  an 
orthogonal  photograph,  a stereo  model  is  used  to  orient  and  adjust  the 
photo  image.  However,  during  the  subsequent  scanning  operation  only  one 
of  the  photographs  is  considered.  This  being  the  case,  it  appears  obvious 
that  all  detail  falling  in  the  shadows  will  be  omitted  from  the  resultant 
orthophoto.  It  may  be  possible  to  circumvent  this  problem  by  judiciously 
considering  other  photo  models  of  the  area  under  consideration  assuming 
adequate  photography  (ie.  adequate  photo  coverage).  This,  in  turn,  will 
dictate  that  at  least  twice  as  many  photographs  must  be  scanned.  Either 
the  additional  time  required  or  inadequate  photo  coverage  could  result  in 
this  becoming  a much  less  viable  solution  as  a rapid  mapping  alternative. 


Devastated  Areas  - Assuming  severe  devastation  one  must  assume  that  the 
detail  shown  on  the  APPS  photographs  would  be  largely  non-exi stant.  This, 
in  turn,  would  likely  dictate  performance  of  a new  control  survey.  Since 
a basic  mapping  job  would  be  required,  it  would  appear  prudent  to  allow  the 
mappers  to  decide  what  technique  would  be  most  appropriate  in  line  with 
available  source  materials,  equipment  and  manpower. 


4.0  System  Simulation  Study 


A system  analysis  of  the  TSS  was  conducted  to  determine  the  operating 
performance  of  the  system.  The  various  specifications  concerning  the 
equipment  and  human  resource  complement  of  the  TSS  as  of  January,  1978 
were  used.  The  analysis  was  performed  by  means  of  constructing  a computer- 
based  simulation  of  the  system.  The  following  sections  describe  the  design, 
construction  of,  and  results  produced  by  the  model. 

4.1  Simulation  - Basic  Concepts 

In  business,  industry  and  government  today,  large-scale,  complex  pro- 
jects are  the  rule  rather  than  the  exception.  In  order  to  minimize  the 
high  cost  and  risk  of  such  projects,  the  planning  and  implementation  phases 
must  be  as  efficient  as  possible.  Preliminary  studies  to  assess  the  suita- 
bility of  plans,  before  they  are  adopted,  are  thus  vital  to  efficient  and 
economical  execution  of  all  projects  of  any  considerable  size.  One  techni- 
que of  performing  such  pilot  studies,  which  yields  reliable  results  while 
being  economically  tractable,  is  simulation. 

Simulation  can  be  described  as  the  process  of  designing  an  algorithmic/ 
mathematical  description  of  a system,  subsystem  or  process  and  conducting 
experiments  with  this  description  for  the  purpose  of  either  understanding 
the  behavior  of  the  system,  subsystem  or  process,  or  of  evaluating  various 
strategies  for  the  operation  of  the  system,  subsystem  or  process.  This 
fundamental  process  of  designing  the  algorithmic/mathematical  system  des- 
cription, is  generally  referred  to  as  modelling. 

A model  is  a representation  of  a system,  it  is  not  a replica;  it  con- 
sists of  a description  that  may  be  physical,  verbal  or  abstract  in  form, 
together  with  a set  of  operating  rules.  However,  a basic  requirement  for 
any  model  is  that  it  should  describe  the  system  is  sufficient  detail  for 
the  behavior  of  the  model  to  provide  valid  predict  ons  of  the  behavior  of 
the  system.  More  generally,  the  characteristics  of  the  model  must  corres- 
pond to  the  character i s t i cs  of  the  system  being  modelled. 


f ^ 

Figure  4.1  shows  the  concept  of  a model.  The  shape  has  been  idealized 
to  show  that  the  model  is  usually  a simplification  of  real  life.  Para- 
meters specifying  characteristics  or  attributes  of  both  system  ard  model 
appear  in  each  case.  Input  to  and  Output  from  the  real  system  have  been 
formalized  in  the  model  and  correspondence  between  input  to  both  system 
and  model  have  been  identified.  However,  the  two  outputs  do  not  neces- 
sarily have  the  same  correspondence.  As  both  the  system  and  the  model 
can  be  considered  as  functions  that  transform  input  to  output,  the  output 
from  a suitable  model  might  be  used  to  infer  the  output  from  the  system 
that  it  represents. 

For  a simulation  study  to  be  truly  useful,  careful  attention  must 
be  paid  to  the  formulation  of  the  basic  system  model.  This  basic  system 
model  structure  will  usually  contain  several  subsystems,  which,  in  turn, 
are  composed  of  elements,  whose  operation  are  specified  by  certain  rela- 
tionships. The  formulation  of  the  system  model  must  them  proceed  from 
the  "bottom-up",  as  depicted  in  Figure  4.2,  taking  into  account  all  those 
features  from  which  the  analyst  builds  up  a logical  structure  for  a simu- 
lation experiment,  starting  with  the  basic  components  of  the  system  from 
which  the  "final"  model  is  constructed.  Once  the  first  version  of  the 
"final"  model  is  constructed,  the  first  phase  of  the  simulation  study  can 
begin  - exercising  the  model  that  currently  represents  a particular  por- 
tion  of  the  system,  or  perhaps,  the  entire  system  itself. 

At  this  point  in  the  simulation  study,  the  true  value  of  the  model 
is  just  coming  into  focus.  The  simulation/modelling  process  is  most  effec- 
tive when  used  in  an  iterative  fashion.  One  such  iteration  scheme  is 
shown  in  Figure  4.3.  A simulation  experiment,  based  on  the  current  state 
of  the  system  model,  would  be  run  and  the  results  produced  would  be  ana- 
lyzed. Analysis  of  the  output  would  suggest  modifications  to  the  model, 
or  the  operating  strategies  that  drive  the  model,  and  a second  simulation 
run  could  be  made  after  performing  the  required  modifications.  Thus,  step 
by  step,  we  gain  more  knowledge  about  the  system  design  and  its  perfor- 
mance until  there  is  sufficient  information  to  make  final  recommendations 
about  the  system,  or  part  thereof,  to  be  implemented. 


CONSTRUCTION  OF  A MODEL 
OF  THE  REAL  SYSTEM 


SYSTEM 


SUBSYSTEMS 


ELEMENTS 


RELATIONSHIPS 


FIGURE  4.2  BASIC  SYSTEM  MODEL  FORMULATION 
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This  overall  s imul at  ion/mode  1 I ing/ i terat ion  process,  allows  various 
design  decisions  concerning  extremely  complex,  and  costly,  systems  to  be 
evaluated  and  compared  without  having  yet  built  the  target  system.  Simply, 
simulation  allows  management  to  ask  the  question:  "What  would  happen 
if...?"  (ie.  "I  added  another  light  table  here?"  or  "I  substituted  an 
Interactive  Graphics  System  for  Drafting?",  etc.) 

4.2  Generalized  System  Model 

4.2.1  System  Model  Content  / Organization 

The  overall  structure  of  the  model  of  the  TSS,  as  put  forth  in  this 
study,  is  shown  in  Figure  4.4,  in  stylized  fashion.  The  functional  sys- 
tem elements  are  three  in  number  and  consist  of  the  following: 

1 - Driving  Functions 

2 - Subsystem,  Module  and  Equipment  Models 

3 - Route  Control  Logic 

The  driving  functions  of  the  system  model  generate  product  requests 
and  then  control  their  paths  through  the  TSS.  For  product  request  genera- 
tion, a product  request  is  first  selected  from  the  product  distribution 
function.  Then,  the  attributes  describing  the  selected  product  request 
are  generated  by  the  product  attribute  distribution.  With  the  products 
and  their  attributes  chosen,  the  requests  enter  the  TSS  at  a pace  that 
is  controlled  by  the  inter-arrival  rate  function.  This  inter-arrival 
rate  simulates  customer  demand  upon  the  TSS. 

Once  entered  in  the  TSS,  a product  follows  a pre-determi ned  produc- 
tion path  through  the  TSS  as  specified  in  the  route  control  matrix.  Another 
driving  function  affecting  TSS  throughput  is  the  van  separation  distance 
matrix  because  the  movement  between  modules  is  impacted  by  the  amount  of 
distance  between  the  modules.  Figure  4.5  depicts  a reasonable  TSS  con- 
figuration which  was  used  to  calculate  the  distances  between  modules. 

These  inter-module  distances  are  listed  in  the  van  separation  distance 
matrix. 
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FIGURE  4.5  TSS  SUBSYSTEM  LAYOUT  SCALE:  1"  - IOO' 
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The  route  control  logic  is  responsible  for  guiding  the  product  along 
its  pre-determined  "assembly"  path  to  completion.  Thus,  the  system  model 
driving  functions  modulate  the  dynamic  characteristics  of  the  TSS  model. 

The  simulation  of  the  physical  elements  of  the  TSS,  ie.  equipment, 
vans,  etc.,  was  done  in  a modular  fashion.  At  the  basic  level,  models 
were  created  for  each  piece  of  equipment.  These  equipment  models  were  then 
assigned  to  their  respective  vans  which,  in  turn,  were  organized  according 
to  subsystem.  Also,  within  each  van,  a number  of  personnel  is  assigned. 

The  personnel  in  each  van  are  assumed  to  be  able  to  operate  any  equipment 
within  that  van.  The  modularity  of  the  system  model  allows  for  a logical 
organization  of  the  TSS  elements  and  for  the  capability  to  modify  numbers, 
types  and  locations  of  the  equipments  with  relative  ease. 

The  simulation  language  used  in  the  TSS  System  Analysis  is  the  General 
Purpose  Simulation  System  (GPSS).  The  GPSS  simulation  model  of  the  TSS 
also  includes  specially  prepared  report  generator  subroutines  that  organ- 
ize, summarize,  tabulate  and  neatly  present  the  general  statistical  out- 
put provided  by  the  GPSS  simulation  language.  The  resulting  summarized 
output  reports  on  the  status  and  performance  of  the  TSS  model. 

4.2.2  System  Model  Driving  Functions 

in  the  TSS  system  model,  there  are  several  driving  functions  that 
dynamically  control  the  TSS's  input  and  throughput. 

The  first  driving  function  that  affects  the  system  model's  input 
is  the  product  request  distribution.  The  product  request  distribution 
is  a catalog  of  the  products  that  can  be  produced  in  the  TSS  and  their 
probability  of  occurrence.  This  product  request  distribution  allows 
there  to  be  varying  degrees  of  demand  for  different  products. 

The  next  driving  function  is  the  product  attribute  distribution. 

Each  product  has  attributes,  or  characteristics  such  as  level  of  prior- 
ity, number  of  different  items  requested,  etc.,  which  have  an  impact  on 
a product's  input  into  the  TSS  and  its  subsequent  throughput.  The  various 
product  attributes  each  have  varying  numerical  quantities  which  are  ap- 


L. 


-45- 


portioned  in  a probability  distribution.  From  this  product  attribute  dis- 
tribution then,  product  attri tubes  can  be  generated  for  each  product  request. 

Another  input  driving  function  is  the  product  request  inter-arrival 
rate.  This  inter-arrival  rate  controls  the  number  of  product  request 
that  will  be  generated  during  a given  time.  For  example,  in  this  system 
model,  an  inter-arrival  rate  of  three  product  requests  per  hour  was  used. 

This  rate  was  chosen  so  that  the  TSS's  capabilities  would  be  stressed.  The 
product  request  inter-arrival  rate  can  easily  be  varied  from  simulation  to 
simulation  to  reflect  different  loads  on  the  TSS's  production  facilities. 

The  route  control  matrix  is  a major  driving  function  concerning  TSS 
product  throughput.  The  route  control  matrix  contains  the  pre-determined 
production  paths  for  each  product.  As  a product  flows  through  the  TSS 
on  its  way  to  becoming  a finished  product,  it  must  do  a route  control 
matrix  look-up  for  each  step  of  its  production.  Thus,  the  route  control 
matrix  maps  out  a pre-determined  production  sequence  for  each  product. 

The  van  separation  distance  matrix  also  figures  into  TSS  throughput. 
Given  a certain  TSS  layout  or  configuration  distance  between  each  van  is 
measured  and  stored  in  the  system  model's  van  separation  distance  matrix. 
These  distances  are  used  to  reflect  the  travelling  times  of  the  products 
between  vans. 

It  should  be  noted  that  the  model  is  modular  to  the  extent  that  a 1 1 
of  tf  iriving  functions  can  be  changed  easily  and  quickly  without  changing 
the  i .'el  structure.  Hence,  the  exact  same  model  can  be  driven  with  differ- 
ent function  specifications  so  as  to  investigate  their  effect  on  TSS  perfor- 
mance. 

A. 3 System  Model  Implementation 

In  order  to  pr-jserve  the  flexibility  naturally  inherent  in  a simulation 
study,  while  providing  for  a closely  parallel  relationship  between  the 
functioning  of  the  model  and  the  actual  operation  of  the  TSS,  a specialized 
scheme  was  developed  for  implementation  of  the  model. 


-A6- 


The  implementation  scheme  focused  primarily  upon  the  integration  of 
four  types  of  elements  into  an  overall  TSS  simulation  model.  These  ele- 
ments, or  submodels,  consist  of  the  following: 

1 - Operations  Module  Element 

2 - Generalized  Module  Element 

3 - Generalized  Equipment  Element 

4 - Transaction  Route  Control  Element 

Incorporation  of  these  functional  system  elements  into  the  overall 
system  model  concept,  immediately  allowed  for  the  dissolution  of  an 
extremely  complicated  system  analysis  and  modelling  task  into  several 
smaller,  more  tractable,  tasks.  Hence,  from  the  viewpoint  of  simulation 
and  modelling,  the  construction  of  an  extremely  complex  model  has  been 
reduced  to  the  construction  of  several  less  complex  submodels.  The 
logic,  which  allows  those  submodels  to  be  integrated  in,  collectively, 
a model  of  the  entire  TSS. 

The  concepts  involved  in  the  design  and  implementation  of  each  of 
the  four  elements  will  be  discussed  in  the  following  sections. 

4.3.1  Operations  Module  Model 

The  operations  module  forms  the  foundation  of  the  entire  TSS  system, 
for  it  is  the  place  where  transactions  (ie.  requests  for  products)  are 
originated,  planned  and  finally  return,  when  they  are  completed.  It  is, 
in  essence,  the  nerve  center  of  the  TSS.  The  organization  of  its  model 
is  depicted  in  Figure  4.6.  The  following  text  presents  the  methodology 
with  which  the  model  was  constructed  and  the  logic  by  which  it  operates. 

Since  the  primary  TSS  driving  function  concerns  the  rate  at  which 
requests  for  products  enter  the  operations  module,  the  first  logical  step 
in  analyzing  the  operation  of  the  TSS  was  to  determine  the  inter-arrival 
time  between  "customers".  More  simply  stated,  how  long  is  the  time  delay 
between  requests  for  products  produced  by  TSS?  Upon  examining  the  tech- 
nical data  package,  speaking  with  appropriate  personnel  at  ETL  and  appre- 
ciating the  fact  that  the  simulation  will  be  emulating  a TSS  deployed  in 
a combat  situation,  the  assumption  was  made  that  customers  will  arrive 


in  a Poisson  fashion  with  an  average  i n te r-arr i va i time  of  20  minutes. 
Therefore,  the  GPSS  implementation  of  the  "customer"  arrival  would 
essentially  involve  the  random  sampling  from  the  appropriate  distri- 
bution and  the  creation  of  the  "customer"  entity.  This  entity  will 
then  be  admitted  to  the  customer  queue.  The  GPSS  processor  will  gather 
statistics  for  each  queue  entry  as  to  its  time  of  arrival,  time  of  de- 
parture and  other  transactional  information. 


The  next  logical  step  in  the  operation  of  the  TSS,  is  for  the 
"customer"  to  converse  with  the  operations  officer  (supervisor)  con- 
cerning his  need  for  an  item  that  TSS  produces.  Again,  examination  of 
the  technical  data  package  and  conversations  with  ETL  staff  members  has 
allowed  the  development  of  a function  that  represents  the  "customer"/ 
operations  officer  conversation  length.  It  has  been  determined  that 
conversation  length  is  best  represented  by  an  exponential  distribution 
with  a mean  of  10  minutes.  The  GPSS  implementation  of  the  talk  function 
would  be  similar  to  the  implementation  of  the  customer  arrival  logic. 

As  a result,  a person  who  "comes  to  the  front"  of  the  "customer"  queue 
line  will  sieze  the  supervisor  when  he  next  comes  available.  GPSS  wi 1 1 
then  sample  from  the  appropriate  distribution  and  serve  the  "customer" 
for  a prescribed  time  interval.  As  a result  of  a customer  arriving  and 
conversing  with  the  operations  officer,  the  request  for  a specific  TSS 
product  would  become  apparent. 

After  analyzing  the  operational  information  associated  with  the 
functioning  of  the  TSS  and  deciding  on  a modular,  path  oriented,  model 
topology,  the  definition  of  the  structure  of  requests  was  arrived  at. 
Careful  attention  was  paid  in  designing  the  request  structure  so  as  to 
form  a realistic  loading  effect  on  the  TSS.  The  structure  of  a request 
consists  of  choosing  a product-primary  category  and  appropriate  values 
for  certain  attributes  associated  with  a product.  The  product-primary 
category  consists  of  eight  types  of  products  that  the  TSS  is  responsible 
for  producing.  The  list  and  the  per  cent  of  time  that  the  Operations 
Module  would  issue  a particular  request  type  is  given  in  section  three. 
As  far  as  the  model  is  concerned,  the  end  of  the  conversation  between 
a "customer"  and  the  operations  officer  would  trigger  a sampling  of  the 
distribution  of  the  per  cent  occurence  of  a particular  product-primary 
category.  This  would  result  in  the  creation  of  a transaction  with  the 
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label  of  the  category  chosen. 

The  next  step  in  the  logic  is  to  increase  the  specificity  of  the 
transaction  by  choosing  a product-secondary  category.  The  tables  in 
Section  3 list  the  product-secondary  categories,  and  their  per  cent 
occurrence,  according  to  product-primary  categories.  Again,  special 
care  and  consideration  was  given  to  the  definition  of  these  tables  to 
preserve  realism  in  the  simulation.  During  the  simulation  a random 
sampling  of  the  appropriate  product-secondary  category  distribution  re- 
sulted in  the  assignment  of  a specific  secondary  category  to  the  current 
entity  with  the  appropriate  primary  category  label.  Other  calculations 
and  samplings  were  performed  which  resulted  in  the  assignment  of  various 
parameter  values  (ie.  number  of  copies  of  a particular  map,  priority  of 
request,  etc.)  to  the  current  transaction.  The  total  impact  of  the  afore- 
mentioned activities  and  computations  was  the  creation  of  a bonafide  pro- 
duct/service request. 

At  this  point,  the  logical  flow  path  control  through  the  simulation 
model  must  be  assigned  to  the  current  product  request.  This  is  accom- 
plished by  retrieving  the  appropriate,  pre-defined,  path  information  from 
a storage  array  and  assigning  it  to  the  current  transaction.  The  trans- 
action will  then  contain  all  the  necessary  information  to  traverse  the 
TSS.  It  should  be  noted  that  the  request  generator  and  path  generator 
have  no  counter  parts  in  the  TSS  system.  They  appear  in  the  model  for 
the  sake  of  uniformity  and  reduction  in  the  logical  complexity  of  the 
model.  Also,  their  functions  were  performed  in  zero  simulation  time  so 
that  the  operation  of  the  model  was  realistic.  It  should  also  be  noted 
that  the  tables  in  Section  3 include  information  pertaining  to  the  request 
parameters  (attributes).  Namely,  the  types  of  attributes,  the  products 
they  are  associated  with,  the  values  they  can  assume  and  the  distributions 
governing  the  assignment  of  those  values. 

Now  that  the  "customer"  has  finished  speaking  with  the  supervisor 
and  a bonafide  request  has  been  created,  with  a specified  priority,  GPSS 
will  place  the  "customer"  and  his  request  in  a queue  corresponding  to 
the  priority  of  the  request.  These  queues,  as  shown  in  Figure  4.6,  are 
the  high,  medium  and  low  priority  queues  and  are  entered  via  a buffer 
(traffic  cop)  block.  Once  the  customer  resides  in  a server  input  queue 
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a certain  logic  must  be  applied  to  determine  which  server  will  serve  him. 

In  the  case  where  a request  is  for  verbal  information,  the  supervisor  will 
personally  service  the  customer  for  the  sampled  conversation  time  length. 

For  a moment,  let  us  examine  the  output  queues  that  feed  each  server 
as  shown  in  Figure  4. 6.  These  output  queues  correspond  to  the  servers, 

(of  which  only  three  of  the  five  are  shown  for  clarity).  These  queues 
contain  completed  TSS  products  that  must  be  verified  for  quality  assur- 
ance and  distributed  by  the  appropriate  server.  When  the  request  is  first 
created  by  the  C 6 C subsystem,  it  is  tagged  with  the  number  of  the  server 

it  to  the  TSS.  When  the  product  is  com- 
to  route  the  product  to  the  output  queue 
of  the  original  server.  The  particular  server  will,  when  just  becoming 
available,  scan  his  output  queue  for  residents.  GPSS  will  make  note  of 
the  highest  priority  present.  The  server  will  then  scan  the  input  queues 
to  ascertain  whether  or  not  there  exist  any  inputs  of  a higher  priority. 

If  there  exist  none,  the  server  will  be  siezed  by  the  highest  priority 
resident  in  the  output  queue.  The  server  will  then  examine  the  product- 
primary/secondary category  parameters  and,  with  the  help  of  a quality 
assurance  time  function,  perform  a service  for  a prescribed  amount  of  time. 
If  there  were  a resident  in  the  medium  or  low  priority  input  queues,  and 
his  priority  were  higher  than  the  output  queue  residents  priority,  then 
the  server  would  service  that  customer.  Again,  the  server  having  examined 
the  customer  request  parameters  will  service  the  input  request  for  a spe- 
cific amount  of  time,  prescribed  by  sampling  from  the  delay  function. 

In  the  special  case,  where  there  is  a resident  in  the  high  priority 
input  queue,  a preemption  will  occur.  In  essence,  GPSS  will  interrogate 
the  servers  to  determine  the  servers  who  are  currently  servicing  input 
requests  or  output  requests  of  priority  medium  or  low.  The  first  such 
server  detected  will  be  forced  Lo  stop  (preempt)  his  current  activity  and 
service  the  high  priority  request.  The  request  that  was  interrupted  will 
continue  to  be  served  upon  the  server's  completion  of  the  high  priority 
task.  This  logic  discipline  has  been  carefully  prepared  to  as  to  reflect 
the  realistic  operation  of  the  CSC  subsystem. 


who  handled  it  before  inputtin 
pleted,  GPSS  utilizes  this  tag 


t 
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Among  the  statistics  which  were  gathered  on  internal  TSS  operations 


are : 

* Per  cent  utilization  of  each  "server"  and  supervisor 

* Number  of  requests  in  queue  for  "server"  by  priority 

* Mean  and  distribution  of  times  in  queue  by  priority 

* Number  of  requests  in  queue  for  supervisor 

Obviously,  conclusions  regarding  the  acceptable  inter-arrival  time 
of  requests  and  the  adequacy  of  manning  within  C 6 C can  be  drawn.  Simi- 
larly, the  logical  process  used  to  construct  the  model  of  the  Operations 
Module  has  been  applied  to  the  internal  operation  of  each  of  the  modules 
in  the  TSS. 

4.3.2  Generalized  Module  Model 

The  TSS  is  an  assemblage  of  modules,  whose  contents  are  people  and 
equipment  responsible  for  performing  a particular  process,  or  part  thereof. 

Therefore,  it  was  relatively  easy  to  build  a generalized  module  model  in 
which  the  models  of  the  specific  equipments  could  be  later  included.  The 
complicated  integral  model  of  people/equ ipment/van  was  divided  into  two 
model  components,  one  of  which  is  the  generalized  van/personnel  mode! 
and  the  other  is  a model  of  the  equipment  content. 

Figure  4.7  depicts  the  organization  of  the  generalized  module  model. 

The  module  model  consists  of  four  basic  entities  which  are: 

I 

1 - Van  Residence  Queue 

2 - Equipment  Capture  Queue 

3 - Equipment  Models 

4 - Personnel  Pool 


In  actuality,  the  equipment  models  are  not  included  in  the  van  model, 
except  for  a logic  interface  which  allows  for  a check  of  the  equipment 
busy/free  status  flag. 


GENERALIZED  MODULE 


Personnel  Pool 
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The  first  action  that  occurs  in  the  operation  of  the  module  model 
involves  the  arrival  of  a request  for  a product,  or  process  that  would 
result  in  a product,  or  part  thereof.  This  request  is  coordinated  with 
the  other  TSS  components  via  the  route  control  logic  and  entered  into  the 
specific  module  as  set  forth  in  the  pre-determined  entries  of  the  route 
control  matrix. 

Upon  entering  the  module,  the  transaction  immediately  enters  the  van 
residence  queue.  The  transaction  will  remain  in  this  queue  until  it  has 
completed  its  specific  tour  through  that  module,  at  which  time  the  appro- 
priate queue  statistics  (see  Section  4.4)  will  be  updated  and  preserved. 
This  queue  has  been  incorporated  into  the  generalized  module  model  so  that 
statistics,  relating  to  transaction  van  residence  times  and  population 
activity,  could  easily  be  extracted  from  the  simulation  study. 

Once  entered  into  the  residence  queue,  the  transaction  will  be  dir- 
ected, via  the  route  control  logic,  to  the  capture  queue  of  the  first 
equipment  needed.  After  entering  the  specific  equipment  capture  queue 
a test  is  continually  performed  to  ascertain  both  the  availability  of  the 
particular  equipment  and  a person  to  operate  that  equipment.  When  the 
test  logic  yields  a positive  result  for  man  and  machine,  the  transaction 
leaves  the  capture  queue,  siezes  both  man  and  machine  and  control  trans- 
fers to  the  specific  equipment  model. 

When  the  transaction  has  completed  its  equipment  use,  it  releases 
both  man  and  machine  and,  under  direction  of  the  route  control,  logic  is 
placed  in  another  equipment  capture  queue  in  the  same  van  or  be  removed 
from  the  van  (and  consequently  from  the  particular  van  residence  queue) 
and  placed  in  another  van.  In  either  case,  the  appropriate  logic  is 
invoked  and  the  process  continued  until  the  product  is  complete. 

When  the  particular  requested  product  has  been  produced,  it  is  re- 
turned to  the  Operations  Module  for  quality  control  and  distribution. 

4.3.3  Generalized  Equipment  Model 


A discussion  of  a generalized  equipment  model  will  be  presented 
instead  of  a discussion  of  each  equipment  contained  in  the  TSS.  This 


— 

has  been  done  because  both  the  basic  structure  and  the  salient  operating 
features  of  each  of  the  equipment  models  are  similar.  In  addition,  the 
program  source  code  listing  is  so  heavily  commented  that  an  understanding 
of  the  basic  equipment  model  will  allow  the  reader  to  explore  those  equip- 
ment models  of  prime  interest  to  himself.  The  basic  GPSS  logic  flow  of 
the  generalized  equipment  model  is  depicted  in  Figure  4.8. 

The  first  action  to  occur,  when  an  equipment  is  captured  by  a trans- 
action, is  for  the  local  iteration  logic  to  analyze  the  attributes  of 
the  product  request.  The  type  of  product  is  identified  by  reference  to 
the  transaction  parameters  that  are  associated  with  primary  and  secondary 
categories.  Once  the  logic  examines  the  attribute  values  and  other  logical 
conditions  it  assigns  the  loop  counter  a numeric  value  defining  the  number 
of  times  the  equipment  function  is  to  be  executed.  For  example,  if  the 
equipment  were  a photographic  plate  maker,  the  number  of  iterations  (and 
consequently,  the  value  of  the  loop  counter)  would  be  the  number  of  plates 
to  be  made,  to  honor  the  requirements  set  forth  by  the  parameters  and  attri- 
butes of  the  transaction. 

Once  the  number  of  iterations  is  defined,  the  actual  emulation  of  the 
real  process  would  be  accomplished.  In  the  case  of  the  platemaker,  GPSS 
would  sample  from  a random  number  generator  and  map  the  sample  into  a 
rectangular  distribution  with  a mean  of  300  seconds  and  a half  width  of 
60  seconds.  Therefore,  the  mapped  time  would  be  5 minutes,  plus  or  minus 
1 minute,  and  would  represent  the  time  delay  one  would  encounter  installing, 
exposing  and  removing  a plate  from  the  equipment.  Statistics  are  auto- 
matically gathered  on  the  activity  of  the  machine. 

After  completion  of  an  iteration,  the  loop  counter  numeric  value  de- 
cremented and  compared  with  zero.  If  all  the  iterations  were  completed, 
the  transaction  would  free  both  captured  equipment  and  server.  Then, 
control  would  be  assumed  by  the  route  control  logic  and  the  transaction 
would  continue  on  its  path  through  the  system.  If  the  iterations  were 
not  all  complete,  the  transaction  would  circulate  around  the  loop  and  the 
mapping  process  would  begin  again. 
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It  should  be  obvious  that  this  basic  single  function  - single  loop 
equipment  model  can  be  incorporated  into  more  sophisticated,  multi-loop/ 
mu  1 1 i -f unct i on  models,  to  emulate  very  complicated  man-machine  processes. 
This  is  what  has  been  done  in  the  development  of  the  models  of  the  TSS 
equipment  complement. 

4.3.4  Transaction  Route  Control 

The  control  and  guidance  of  product  request  transactions  through 
the  TSS  is  accomplished  by  the  transaction  route  control  logic.  The 
transaction  route  control  logic  is  essentially  responsible  for  monitoring 
all  transactions  that  are  in  existence,  at  any  clock  tick,  while  the 
simulation  is  in  progress.  When  a transaction  is  freeing  an  equipment 
and  server,  the  logic  will  examine  the  parameters  and  attributes  of  the 
transaction  to  determine  two  factors.  These  two  factors  are:  (1)  route 
control  matrix  row  address,  (2)  route  control  matrix  column  address. 

The  remaining  portion  of  the  logic  will  retrieve  the  contents  of 
the  matrix  location  as  specified  by  the  row/column  address,  and  then  re- 
solve the  pre-determi ned  packed  information  contained  in  the  number  into 
its  three  component  parts: 

1 - Van  Designation 

2 - Equipment  Designation 

3 “ Logic  Code 

Subsequently,  the  logic  uses  this  retrieve  information  to  direct  the 
transaction  to  its  next  designated  van,  and  then  its  next  designated  equip- 
ment. The  equipment  model  then  uses  the  associated  logic  code  to  assign 
a value  to  the  iteration  loop  counter.  This  process  continues  until  the 
tour  of  the  transaction  through  the  TSS  is  complete. 

This  deterministic  control  structure  was  developed  to  assure  that 
the  path  of  the  transaction  through  the  model  could  easily  be  changed  and 
that  the  path  be  essentially  independent  of  the  model  topology.  The 
developed  logic  performs  well  and  allows  the  model  user  a flexibility 
generally  not  available  in  large  system  simulation  models. 
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copy  of  the  entire  source  code  used  in  the  simulations  reported 
is  contained  in  Appendix  G. 


1 


4.4.1  Simulation  Supplied  Statistics 


The  system  model  provides  us  with  the  following  categories  of 
output : 

a)  Clock  Stat ist  ic 

b)  GPSS  Statistics 

c)  Summary  Statistics 

The  clock  statistic  is  a listing  of  how  many  time  units  occurred 
during  the  simulation  and  of  how  long  the  simulation  lasted.  The  time 
unit  used  in  the  simulation  was  a second.  Seconds  were  chosen  not  be- 
cause production  times  were  accurate  down  to  the  second,  but  because 
variances  in  production  times  could  easily  be  described,  and  in  the 
long  run,  would  produce  more  realistic  statistics.  The  simulation  was 
run  for  144  hours,  ie.  518,400  seconds. 

The  GPSS  statistics  can  be  divided  into  two  parts: 

a)  Queue  Statistics 

b)  Utilization  Statistics 

The  queue  statistics  provided  by  the  system  model  are: 

a)  Queue  Name  - designation  of  the  queue. 

b)  Maximum  Contents  - the  largest  number  of  transactions 
waiting  in  the  queue  at  the  same  time  during  the 
simulation. 

c)  Average  Contents  - average  value  of  the  queue  content. 

It  is  equal  to  the  sum  of  the  times  spent  by  all  trans- 
actions in  the  queue,  divided  by  the  total  simulation 
time. 

d)  Total  Entries  - the  total  number  of  transactions  that 
have  waited  in  the  queue. 

e)  Zero  Entries  - the  total  number  of  queue  entries  that 
experienced  no  waiting. 


f)  Percent  Zeros  - percentage  of  total  queue  entries  which 
experienced  no  waiting. 

g)  Average  Time/Transact  ion  - the  average  time  that  each 
transaction  spent  waiting  in  the  queue  (zero  entries 
are  included  in  this  average). 

h)  SAverage  Time/Transaction  - the  average  time  that  each 
transaction  spent  waiting  in  the  queue  (zero  entires 
are  excluded  from  this  average). 

i)  Current  Contents  - the  current  number  of  transactions 
present  in  the  queue. 

The  utilization  statistics  provided  by  the  system  model  are: 

a)  Storage  Name  - designation  of  the  storage. 

b)  Capac i ty  - number  of  equipments  or  units  of  the  storage 
that  are  ava i 1 abl e. 

c)  Average  Contents  - fraction  of  the  simulation  time  in 
which  the  storage  was  used. 

d)  Average  Utilization  - the  average  contents  divided  by 
the  storage's  capacity  which  gives  the  fraction  of 
simulation  time  for  which  each  element  of  the  storage 
was  used. 

e)  Entries  - the  number  of  transactions  that  have  utilized 
the  storage. 

f)  Average  Time/Transaction  - the  average  time  that  each 
transaction  spent  utilizing  the  storage. 

g)  Current  Contents  - the  current  number  of  transactions 
present  in  the  storage. 

h)  Maximum  Contents  - the  largest  number  of  transactions 
utilizing  the  storage  at  the  same  time  during  the  simu- 
lation. 

In  addition  to  the  GPSS  statistics  which  were  automatically  generated, 
summary  statistics  were  generated  using  logic  written  by  Decilog.  These 
statistics  summarize  the  TSS's  performance  and  include: 

a)  Transaction  Parametric  History  Matrix 

b)  Transaction  Temporal  History  Matrix 

c)  Transaction  Cumulative  Summary  Matrix 
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4.4.2  TSS  Statistical  Interpretation 


To  further  explain  the  simulation  statistics  defined  in  the  pre- 
vious section,  examples  of  these  statistics  will  be  discussed. 

An  example  of  GPSS  generated  queue  and  utilization  statistics  is 
shown  in  Figure  4-9.  These  statistics  are  a "snapshot"  of  the  system 
and  can  be  taken  at  any  time  during  the  simulation.  Note  that  the  GPSS 
generated  statistics  are  cumulative  to  that  point  in  time  in  which  they 
are  printed  out.  The  example  in  Figure  4-9  illustrates  the  statistics 
generated  for  the  Plate  Processing  Module  and  its  various  equipment  at 
the  end  of  the  144-hour  (or  518,400  second)  simulation. 

To  begin  with,  the  Queue  Name  column  of  the  Van  Input  and  Equipment 
Queue  Statistics  designates  the  names  of  the  queues  for  the  van  and  each 
piece  of  equipment.  For  example,  PMK18  is  the  queue  name  for  the  Plate- 
maker  found  in  the  Plate  Processing  Module. 

The  next  column,  Maximum  Contents,  gives  us  the  largest  number  of 
transactions  to  wait  in  a specific  queue,  at  one  time,  during  the  simula- 
tion. Using  the  queue  PMK18,  for  example,  its  Maximum  Contents  was  2. 

Average  Contents  derives  its  value  from  dividing  the  sum  of  the 
times  of  all  the  entries  of  the  queue  by  the  total  simulation  time.  This 
Average  Contents  value  is,  in  effect,  the  expected  number  of  transactions 
to  be  present  in  the  queue,  at  any  one  instant  in  time,  during  the  simula- 
tion. For  queue  PMK18,  we  find  an  Average  Contents  value  of  .019.  Thus, 
at  any  given  time  during  the  simulation,  we  could  expect  there  to  be,  on 
the  average,  .019  transactions  in  the  queue  PMK18. 

Total  Entries  is  a count  of  how  many  transactions  entered  the  queue 
during  the  simulation.  In  our  example,  queue  PMK18,  there  were  38  entries. 

Zero  Entries  is  a count  of  how  many  transactions  entered  the  queue 
and  did  not  have  to  wait.  In  queue  PMK18,  we  see  of  the  38  total  entries, 
there  were  32  zero  or  non-waiting  entries. 
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PLATE  PROCESSING  MODULE  (REPRO) 
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Percent  Zeros  lists  the  percentage  of  total  queue  entries  which  were 
zero  entries.  For  PMKI8,  84.2%  of  the  total  entries  were  zero  entries. 

Average  Time/Transaction  is  the  average  time  that  a transaction 
waits  in  a queue.  This  average  includes  the  zero  waiting  times  of  the 
zero  entries.  For  PMK18,  the  Average  Time/Transaction  is  264.368  secs. 

$Average  Time/Transaction  is  the  average  time  that  a transaction 
which  must  wait,  (non-zero  entry),  waits  in  a queue.  This  average  ex- 
eludes  zero  entries  so  that  only  transactions  with  wait'ng  times  are 
averaged  together.  This  average  value  is  normally  higher  due  to  the 
omission  of  the  zero  entries.  In  this  case,  PMK18,  the  SAverage  Time/ 
Transaction  is  1674-333  secs. 

Finally,  the  Current  Contents  column  gives  the  number  of  trans- 
actions currently  present  in  the  queue.  For  the  queue  PMK18,  we  find 
there  are  no  transactions  waiting  in  the  queue  at  the  present  time. 

The  '-ext  grouping  of  GPSS  statistics  are  the  utilization  statistics. 
Looking  at  the  Equipment  Utilization  Statistics  section  of  our  example, 
the  Storage  Name  column  designates  the  name  of  the  "storage"  that  repre- 
sents the  piece  of  equipment;  for  example,  PMK18. 

The  Capacity  column  tells  us  the  number  of  elements  or  equipments 
that  are  available  in  the  storage.  In  PMK18,  we  find  a Capacity  of  one, 
so  there  is  only  one  piece  of  equipment  available  in  that  storage. 

Average  Contents  derives  its  value  from  dividing  the  sum  of  all  the 
times  during  which  the  storage  was  utilized  by  the  total  simulation  time. 
This  Average  Contents  value  is,  in  effect,  the  fraction  of  the  simulation 
time  in  which  the  storage  was  used.  PMK18,  for  example,  was  used  .106  or 
10.6%  of  the  total  simulation  time. 

Average  Utilization  is  the  Average  Contents  of  a storage  divided 
by  its  Capacity  (number  of  elements).  This  value  would  then  be  the 
fraction  of  simulation  time  for  which  each  element  of  the  storage  was 
used.  In  PMK18,  the  Capacity  is  one  so  that  its  Average  Utilization  is 
.106. 
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The  Entries  column  is  a count  of  how  many  transactions  entered  and 
used  the  storage.  In  our  example,  PMK18,  38  transactions  utilized  the 

storage.  j 

Average  Time/Transaction  is  simply  the  average  time  that  each  trans- 
action has  spent  utilizing  the  storage.  The  Average  Time/Transaction  in 
PMK1 8 is  1449.474  secs. 

The  Current  Contents  is  a count  of  the  number  of  transactions  cur- 
rently utilizing  the  storage.  In  the  example,  there  are  zero  transactions 
now  utilizing  PMK1 8. 

Finally,  the  Maximum  Contents  column  tells  us  the  largest  number  of 
transactions  utilizing  the  storage  at  the  same  time  during  the  simulation. 

For  PMK18,  there  was  a maximum  of  one  transaction  present  at  any  one  time 
during  the  simulation  because  there  was  only  one  PMK18. 

To  summarize  the  TSS's  performance,  three  tables  of  statistics  were 
generated . 

The  first  of  these  is  the  Transaction  Parametric  History  Matrix. 

This  matrix  gives  a listing  of  all  transactions  that  have  been  requested 
during  the  simulation  and  their  corresponding  attributes.  This  matrix 
is  structured  in  the  following  manner: 

TRANSACTION  PARAMETRIC  HISTORY  MATRIX 

» 

Matrix  Entry  Definitions  - 


Col umn 

( 

1) 

Transaction  Arrival  Number 

Col umn 

( 

2) 

Primary  Category  Number 

Col umn 

( 

3) 

Secondary  Category  Number 

Col umn 

( 

4) 

- A Attribute  Value 

Co  1 umn 

( 

5) 

B Attribute  Value 

Col umn 

( 

6) 

C Attribute  Value 

Column 

( 

7) 

D Attribute  Value 
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Column  ( 8) 

Column  ( 9) 

Column  (10) 

An  illustration  of  the  first  six  rows  (transactions)  of  the  output 
fo 1 1 ows : 
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As  an  example,  the  first  transaction  has  a Primary  Category  number 
of  4 and  a Secondary  Category  of  4.  The  attributes  describing  this  trans- 
action are  then  listed  in  the  subsequent  columns.  Thus,  the  Transaction 
Parametric  History  Matrix  is  a record  of  the  TSS  input. 


The  next  summary  listing  is  the  Transaction  Temporal  History  Matrix. 
This  matrix  gives  a listing  of  the  transactions  that  the  TSS  completed 
during  the  simulation  and  their  pertinent  production  times.  This  matrix 
organizes  transactions  in  order  of  their  completion  and  is  structured  in 
the  following  manner: 


TRANSACTION  TEMPORAL  HISTORY  MATRIX 


Matrix  Entry  Definitions  - 


Column  (1)  * Transaction  Arrival  Number 

Column  ( 2)  - Primary  Category  Number 

Column  ( 3)  * Secondary  Category  Number 
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An  illustration  of  this 
fol lows : 


first  six  rows 


(transactions)  of  the  output 
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The 

first  transaction  to 

be  completed 

was 

the  second 

transact i 

on  to 

enter  the  TSS.  From  columns 

two  and  three 

we 

see  that 

the 

product 

has  a 

P r i ma  ry 

Category  number  of  one  and 

Secondary  Category 

number  of  one 

. The 

columns  that  follow  list  important  times  concerning  production.  Columns 
four  and  five  contain  the  time  at  which  a transaction  enters  the  TSS. 
Columns  six  and  seven  list  the  time  at  which  a transaction  exits  the  TSS 
Columns  eight  and  nine  contain  the  total  time  in  which  a transaction  re- 
sides in  the  TSS.  Column  ten  lists  the  portion  of  the  residence  time  in 
which  a transaction  spends  in  transit  within  the  TSS.  Thus,  the  Trans- 
action Temporal  History  Matrix  is  a record  of  TSS  output. 


The  final  summary  listing  is  the  Transaction  Cumulative  Summary 
Matrix.  This  matrix  lists  each  product  type  by  each  priority  level  with 
their  pertinent  production  times.  This  matrix  is  structured  in  the  follow- 
ing manner: 


. 1 


J 
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TRANSA.CT  I ON  CUMULATIVE  SUMMARY  MATRIX 


Matrix  Entry  Definitions  - 


Co  1 umn 

( 1) 

- 

Primary  Category  Number 

Co  1 umn 

( 2) 

- 

Secondary  Category  Number 

Co  1 umn 

( 3) 

- 

C Attribute  Value 

Col umn 

( 4) 

- 

Number  of  Times  Entered  (Absolute) 

Col umn 

( 5) 

- 

Portion  of  Total  Entries  (Parts/10000) 

Col umn 

( 6) 

- 

Number  of  Times  Exited  (Absolute) 

Col umn 

( 7) 

- 

Portion  of  Total  Exits  (Parts/10000) 

Col umn 

( 8) 

- 

Average  Residence  Time  (Hrs  - Portion) 

Col umn 

( 9) 

- 

Average  Residence  Time  (Min  - Portion) 

Col  umn 

(10) 

* 

Average  Travel  Time  (Parts/10000) 

An  i 1 lustration 

of  Product  1-1  and  its  three  levels  of 

priori ty 

described  in 

the 

form  shown  above,  follows: 
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Co  1 umn 

three 

denotes  the  priority  level;  the  higher  the 

number,  the 

hi gher  the  priori ty. 

Columns  eight  and  nine  list  the  average  resi 

dence 

time  that  a 

product  i 

of  a certain  priority  level  spends  in  the  TSS. 

Note 

that  as  the  priority  level  of  a product  increases,  the  average  residence 
time,  ie.  production  time,  decreases.  Thus,  the  Transaction  Cumulative 
Summary  Matrix  is  a record  of  TSS  throughput. 
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5.0  Conclusions  6 Recommendations 


Four  comparable  simulation  experiments  were  performed.  These  were: 

1 . January , 1 978  T . D . P. 

2.  Same  as  1 with  doubled  Drafting,  doubled  Rectifier  I,  and 

Camera  Modules. 

3.  Decilog  modified  version,  described  below. 

4.  Same  as  3 with  Interactive  Graphics  System  substituted 

for  one  Drafting  Module  and  an  Analytical  Stereoplotter 
added  to  Recti fier. 

The  following  sections  describe  the  results  of  each  simulation  in 
chronological  order,  and  a later  section  will  show  numerical  comparisons 
among  all  configurations.  All  simulations  were  run  with  identical  product 
requests  at  a rate  of  three  per  hour. 


5.1  January,  1978  T.D.P.  Simulation 

Decilog  was  instructed  to  simulate  the  Corps  TSS  as  consisting  of 
one  each  of  the  individual  Modules,  except  Press,  of  which  four  were  in- 
cluded. This  yielded  a total  of  23  Modules. 

"Bottlenecks"  were  defined  as  equipments  which  generated  a queue 
of  twenty  or  more  transactions.  Undercapacity  was  defined  as  an  equipment 
which  was  utilized  more  than  67%  of  the  time.  Table  5-l  lists  the  equip- 
ments, by  Module,  which  met  either  or  both  of  these  criteria  at  the  end 
of  144  hours. 


J 


TABLE  5-1 


HIGH  TRAFFIC  RESISTANCE  - JAN.  1978  T.D.P. 


MODULE  6 EQUIPMENT 

QUEUE  LENGTH 

UTILIZATION  (%) 

Draft i ng 

4 Drafting  Tables 

21 

3A.4 

Light  Table 

10 

92.0 

Synthes i s 

Light  Table 

21 

95.5 

Recti f i er  1 

Auto.  Fi 1m  Processor 

6 

67.0 

Recti f ier  II 

APPS 

12 

96.0 

Photomechan i ca 1 

Photoprocessing  Machine 

17 

72.1 

Camera 

Copy  Camera 

55 

96.0 
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The  above  results  were  communicated  to  the  Engineer  Topographic 
Laboratory  and  Dec i log  was  directed  to  double  capacity  in: 

Drafting 
Rectifier  1 
Camera 


5.2  Modified  January  1978  T.D.P.  Configuration 

The  effect  of  including  2 Drafting  Modules,  2 Rectifier  1 Modules 
and  2 Camera  Modules  in  the  second  simulation  was  to  increase  the  total 
module  count  to  26. 

» 

The  results  of  this  module  increase  are  shown  in  Table  5*2. 

TABLE  5*2  HIGH  TRAFFIC  RESISTANCE  MODIFIED 

JAN.  1978  T.D.P. 


MODULE  6 EQUIPMENT 


QUEUE  LENGTH 


UTILIZATION  {%) 


* Drafting 

8 Drafting  Tables 
2 Light  Tables 

Synthes i s 

Light  Table 

* Rectifier  I 

2 Auto.  Film  Processors 

Rect i f ier  II 


Photomechanical 

Photo  Processing  Machine 


* Camera 

Copy  Camera 
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TABLE  5-2  (cont'd) 

* Indicates  Module  Doubled 

A detailed  analysis  of  the  differences  between  the  original  and 
modified  versions  was  carried  out.  In  the  Drafting  area,  the  light 
table  utilization  remained  excessive,  however,  queues  for  both  drafting 
tables  and  light  tables  was  acceptable.  It  was  found  that,  by  reorgani- 
zing these  Modules  to  increase  the  number  of  light  tables  and  decreases 
the  number  of  drafting  boards,  there  should  be  no  problem  with  Drafting.* 

The  relatively  low  drafting  table  utilization  apparently  was  due 
to  a shortage  of  personnel  in  Drafting,  and  it  was  recommended  that  the 
number  be  increased. 

Both  Rectifier  I and  Photomechanical  fell  out  of  the  problem  range, 
based  on  the  above  stated  criteria.  In  the  case  of  Rectifier  I this  was 
a strai ghtforward  result  of  doubling.  In  the  case  of  the  Photo  Processing 
Machine,  however,  the  result  is  more  subtle. 

Although  the  Photo  Processing  Machine  Utilization  is  still  high,  it 
fell  within  the  acceptable  range.  This  was  due  to  the  addition  of  the 
Automatic  Film  Processor  in  Rectifier  I,  and  surprisingly  (at  the  time) 
because  of  the  fact  that,  when  Rectifier  I was  doubled,  an  additional 
Printer/Enlarger  was  introduced  into  the  TSS.  These  two  equipments  took 
some  of  the  load  off  the  Photo  Processor  Machine,  and  led  to  further 
analysis  of  the  results  which  will  be  discussed  below. 

Rectifier  II,  which  was  not  doubled,  remained  excessively  high  in 
Utilization  and  shows  an  increased  queue.  The  increased  queue  is  due  to 
the  fact  that  more  requests  worked  their  way  through  the  TSS,  and  were 
ready  for  APPS  processing. 

* Subsequently,  and  independently,  the  IEET  replaced  drafting  boards 
with  light  tables,  and  increased  the  Module  count  to  three.  This 
new  configuration  will  be  simulated  in  the  near  future. 
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Despite  the  fact  that  two  Copy  Cameras  were  now  available,  the  Copy 
Camera  queue  remained  essentially  constant,  ie.  55  vs.  5^- 

Total  Throughput,  of  course,  increased.  Table  5*3  shows  the  total 
number  of  requests  served  for  each  equipment  for  the  original  and  the 
mod ified  T.D.P.'s. 

TABLE  5*3  THROUGHPUT  AT  CRITICAL  EQUIPMENTS 

NO.  PRODUCTS  PROCESSED  ORIGINAL  3 MODULES  DOUBLED 

1 1 22 

16  39 

Synthes  i s 

Light  Table  52  55 

* Rectifier  I 

Printer/Enlarger  58  85 

Auto.  Film  Processor  66  9^ 

Rect i f i er  II 

APPS  15  19 

Photomechan i ca 1 

Photo  Processing  Machine  55  62 

* Camera 

Copy  Camera  6 16 


* Drafting 

Drafting  Tables 
Light  Table(s) 


* Indicated  Doubled. 

The  large  increase  in  requests  served  by  the  Printer/Enlarger,  which 
had  not  been  a high  resistance  equipment  in  the  unmodified  version,  pro- 
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vided  a clue  for  further  analysis.  It  was  determined  that  many  requests 
involving  Image  Based  Products  were  recirculating  among  the  same  pieces 
of  equipment,  and,  were,  consequently,  delayed  and  re-delayed  in  queues. 

This  fact  led  the  authors  to  the  conclusion  that,  by  reorganizing  the 
locations  of  equipment  within  sub-systems,  a more  product-oriented  and 
more  efficient  TSS  design  could  be  achieved.  With  the  concurrence  of 
ETL , the  changes  to  the  TSS  design  described  in  the  next  section  were 
i ncorporated . 

5-3  Version  "B"  TSS  Configuration 

The  following,  minor,  changes  in  the  TSS  equipment  list  and  configura 
tion  were  made.  In  all  cases  where  equipment  was  added,  it  was  determined 
that  the  equipment  fit  comfortably  in  the  Modules.  In  fact,  more  free 
floor  space  was  available  with  the  reconfiguration. 

1.  Retain  double  Drafting. 

2.  Rectifier  1:  add  one  Frame  Rectifier.  Retain  2 Modules. 

3.  Rect i f ier  II: 

a)  delete  3 draf t i ng/ 1 i ght  tables  to  make  room  for 
equipment  to  be  added.  (Tnese  previously  had  very 
low  utilization). 

b)  add  one  Automatic  Film  Processor 

c)  add  one  Printer/Enlarger 

d)  add  one  Copy  Camera 

!♦.  Camera 

a)  delete  one  (of  two)  Copy  Cameras 

b)  add  one  Printer/Enlarger 

c)  add  one  Automatic  Film  Processor 

5.  Synthesis:  add  one  light  table. 
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A review  of  the  above  changes  will  reveal  that  the  IBP  subsystem 
and  the  REPRO  subsystem  have  been  given  redundant  capabilities.  The  TSS 
is  thus  more  product-oriented.  Time  is  not  wasted  unnecessarily  from 
Module  to  Module,  and  a greater  degree  of  flexibility  is  available  in 
subsystem  and  Module  deployment. 

This  TSS  configuration,  Version  "B",  or  the  Decilog  modified  con- 
figuration was  then  simulated  under  exactly  the  same  conditions  as  Ver- 
sion A,  and  the  results  for  the  critical  equipments  are  shown  in  Table  5*4. 

TABLE  5-4  HIGH  TRAFFIC  RESISTANCE  - DECILOG  MODIFIED  TSS 


MODULE  5 EQUIPMENT 


QUEUE  LENGTH 


UTILIZATION  (%) 


Synthes i s 

2 Light  Tables 

Draft i ng 

8 Drafting  Tables 
2 Light  Tables 


Rectifier  I 

Printer/Enlarger 
Automatic  Film  Processor 


Recti f ier  II 


Automatic  Film  Processor 

Printer/Enlarger 

Copy  Camera 


Camera 


Copy  Camera 

Pr i nter/Enl arger 

Automatic  Film  Processor 
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Drafting,  having  remained  essentially  the  same,  the  comments  re- 
garding modified  Version  A above,  apply.  The  Image  Based  Products  pro- 
blems have  essentially  disappeared.  The  serious  problem  with  the  Copy 
Camera  in  Camera,  remains.  However,  it  should  be  obvious  that,  an  in- 
telligent commander  would  route  some  Copy  Camera  requests  to  Rectifier  II, 
thus  relieving  this  problem. 

In  addition  to  the  above,  ETL  wished  to  simulate  the  effect  of  add- 
ing an  Interactvie  Graphics  System  (IGS)  to  Drafting,  and  an  Analytical 
Stereoplotter  (ASP)  to  Orthophoto.  This  was  done,  and  is  described  in  the 
next  section. 

5. A Version  "B"  with  IGS  and  ASP 


One  of  the  existing  Drafting  Modules  was  deleted,  and  replaced  by 
an  IGS.  In  addition,  an  ASP  was  added  to  Orthophoto,  however,  no  APPS 
were  deleted.  The  results  of  this  simulation  are  shown  in  Table  S~5 ■ 

TABLE  5-5  HIGH  TRAFFIC  RESISTANCE 

VERSION  "B"  WITH  IGS  & ASP 

MODULE  & EQUIPMENT  QUEUE  LENGTH  UTILIZATION  (%) 

Synthes i s 

2 Light  Tables  11  90 • A 

Drafting  I 

A Drafting  Tables  0 60.9 

Light  Table  1 9' -5 

Draft ing  II 

2 IGS  8 92.6 

Tracing  Table  1 73-0 


TABLE  5-5  (cont'd) 


MODULE  & EQUIPMENT 

Recti fier  II 
APRS 

Automatic  Film  Processor 
Pr i nter/En larger 
Copy  Camera 


QUEUE  LENGTH 


4 

0 

0 

0 


UTILIZATION  (%) 

64.1 
1 1 .0 
A.  4 
16.9 


Orthophoto 

ASP 


4 


77-6 


Camera 

Copy  Camera  53 
Printer/Enlarger  0 
Automatic  Film  Processor  0 


96.0 

14.4 

36.0 


The  results  are  very  similar  to  those  for  Version  "B"  without  the 
IGS  and  ASP.  With  regard  to  production  rate,  the  ASP  definitely  increased 
throughput  and  relieved  the  APPS  load  slightiy.  The  IGS  had  slightly 
counterproductive  effects  on  Drafting.  However,  it  had  been  assumed 
that  a Digital  Data  Base  was  not  available  for  the  IGS,  and,  hence,  had 
to  be  developed  for  each  request.  Since  this  is  very  time  consuming,  it 
is  likely  that,  if  the  data  base  were  deployed  with  the  IGS,  throughput 
would  be  increased. 

Table  5*6  shows  throughput  for  Version  "B"  both  with  and  without 
IGS  and  ASP. 
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TABLE  5-6  THROUGHPUT  - VERSION  "B" 

NO.  REQUESTS  SERVED 


CRITICAL  EQUIPMENTS 

W/0 

IGS  & ASD 

WITH  IGS 

Synthes i s 

2 Light  Tables 

94 

95 

Drafting  1 

4 Drafting  Tables 

20 

39 

1 Light  Table 

14 

35 

Draft i ng  II 

2 IGS 

- 

25 

Recti f ier  1 

Printer/Enlarger 

35 

27 

Automatic  Film  Processor 

43 

41 

Recti f ier  II 

APPS 

14 

22 

Automatic  Film  Processor 

18 

18 

Pr i nter/En 1 arger 

16 

16 

Copy  Camera 

18 

18  * 

Orthophoto 

ASP 

16 

Camera 

Copy  Camera 

7 

8 

Pr i nter/Enl arger 

40 

40 

Automatic  Film  Processor 

40 

40 

As  stated  above,  there 

is  1 i 

! ttle  di fference 

between  Vers 

with  and  without  IGS  and  ASP  under  the  assumptions  made. 


5.5  Overall  Comparison  of  Systems  Simulated 


There  is  no  question  as  to  the  superiority  of  Version  B over 
Version  A.  Since  this  was  only  a minor  modification  toward  a Product 
Oriented  TSS,  it  is  concluded  that  further  work  in  this  direction  could 
lead  to  increased  efficiency,  lower  module  count  and  enhanced  deployment 
flexibility. 


None  of  the  systems  simulated  could  be  considered  a "qui ck- react  ion" 
system.  It  is  considered  highly  likely  that  a Product-Oriented  system, 
with  some  thought  toward  optimization,  could  meet  the  R.O.C.  requirements. 


Table 

5-6  shows  the  per  cent 

of 

requested  products  completed 

at  the 

end  of  144 

hours  for  Version  A-l, 

(Or 

iginal  January,  1978  T.D.P.) 

; A-2, 

(Mod i f i ed 

January  T.D.P.);  B-l,  (Deci 

log  modified 

conf i gurat ion)  ; 

and 

B-2,  (Deci 

log  configuration  with 

IGS 

and  ASP) . 

TABLE  5-6  % OF  COMPLETED  PRODUCTS 

AT  144  HRS. 

PRIMARY 

CATEGORY 

VERSION 

A-l 

VERSION 

A- 2 

VERSION 

B-l 

VERSION 

B-2 

1 

63.6 

63-9 

66 . 1 

61.5 

2 

33-3 

36.2 

69.1 

55-6 

3 

4.2 

8.0 

38.7 

37-5 

4 

0 

A. 5 

0 

0 

5 

100 

100 

100 

100 

6 

80 

80 

80 

80 

7 

0 

0 

7-7 

0 

3 

52.  1 

40.8 

52.9 

52.8 

SYSTEM 
'"-•■OUOPUT 
1 **  ClfHCY 

50.5 

49.9 

58.8 

53-9 
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The  absolute  values  in  this  table  should  not  be  relied  on,  because  it 
includes  requests  entered  toward  the  end  of  the  144  hour  period,  which 
could  not  possible  have  been  completed.  For  example,  in  Version  B-2, 
Category  3.  37-5%  of  all  products  represents  60%  of  the  expected  value 
of  this  category  which  would  have  been  completed,  had  no  delays  been 
encountered.  In  addition,  Version  A-2,  for  example,  accepted  22  more 
requests  than  Version  A- I , and  the  absolute  number  of  finished  products 
was  14  more  than  A-l. 

The  last  row  in  the  table,  "System  Throughput  Efficiency",  is  a 
valid  relative  comparision  of  the  versions  simulated.  It  is  concluded 
that  a Product  Oriented  System  would  be  most  efficient.  If  the  Digital 
Data  Base  were  available,  it  is  probable  that  Version  B-2  would  not  differ 
significantly  from  Version  B-l. 

The  reader  interested  in  the  detailed  statistics  is  referred  to 
in  Appendix  H.  This  appendix  contains  the  print-out  of  all  statistics 
for  all  four  versions  run.  These  statistics  are  in  easily  read  form, 
and  were  generated  by  both  the  GPSS  Report  Generator  and  also  specially 
prepared  Report  Generator  Routines. 

5.6  Recommendations 

Since  the  final  IEET  recommendations  as  to  TSS  configuration  were 
made  at  the  same  time  that  the  work  reported  herein  was  completed,  it 
is  recommended  that  this  highest  priority  be  given  to  a simulation  of  this 
configuration.  This  configuration  consists  of  34  modules.  This  simulation 
should  also  have  the  capability  of  varying  the  number  of  personnel  per 
module  to  resolve  the  staffing  problems  encountered  to  date. 

Consideration  should  be  given  to  a reconfiguration  of  the  TSS  to 
make  the  system  more  product-oriented.  This  should  result  in  reduced 
module  count,  lower  cost,  enhanced  deployment  capability  and  increased 
ef f i c i ency . 
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If  it  is  felt  that  a digital  data  base  will  be  deployed  with  the  TSS, 
the  simulation  should  be  re-run,  assuming  the  data  base.  This  would  have 
a significant  effect  on  throughput. 

The  model  should  be  modified  to  include  intelligence  in  the  Route 
Control  Matrix.  This  intelligence  should  allow  parallel  processing  of 
all  requests.  In  Version  B,  the  logic  was  developed  to  allow  some 
parallel  paths,  based  upon  earliest  product  completion  it  is  recommended 
that  this  be  included  for  all  products. 


